We have nearly everything working for user impersonation (we’ve switched to using JWT primarily, we can generate tokens on the fly and refresh them, we have a short lived bearer with a long-lived refresh, we parse all of our primary data out of the bearerToken). I’ve studied and better understand how ServiceStacks auth works, but one thing alludes me: how does servicestack determine if it uses the cached session info vs the JWT?
When we swap JWTs to impersonate, some endpoints are using the JWT’s data, and some endpoints seem to use the old Session data (the Admin user instead of my Impersonated user). Sometimes the PopulateSessionFilter wasn’t hit, or the SessionAs() still returns the old data. As an example, some of my AutoQuery endpoints (list screens) return the impersonated users data, and the POST endpoints are creating as the non-impersonated user.
The FromToken property on the Session indicates if the session was created by a JWT or from a cached UserSession.
You shouldn’t be using both, when you switch to use JWT like if you’re using the built-in ConvertSessionToToken it will automatically remove the server session, if you’re doing the JWT switch yourself you’ll want to remove the server session with IRequest.RemoveSession().
Ahhh ok, so we’ll want to clear the current users session (as well as maybe change our server events clients to subscribe via a JWT as stated in the Send JWTs in the HTTP Params documentation). That would make us fully JWT dependent.
But wouldn’t that mess up once we try to impersonate? IE the Token Cookie would be set on login (authenticate), but after we call our Admin restricted GetBearerTokenEndpoint for impersonation, the token cookie is still being sent instead of the new JWT we just got.
How does using the Token Cookie work with refresh tokens? I’ve changed around my implementation some to utilize ss-tok, but noticed that when I get a Token has expired or Invalid token response, the automatic refresh doesn’t occur (it just logs me out). When switching to this method, does it not use the auto-refresh?
Are you using the TypeScript or the C# JsonServiceClient?
The RefreshToken still needs to be populated on the client in order to be able to fetch a new Bearer Token, but it only populates the bearerToken property on the client.
It looks like you may be able to implement a onAuthenticationRequired callback to either set a client cookie locally (in browser) or in the C# client you can use SetTokenCookie(), the alternative way to configure the cookie on the client is to make a request to ConvertSessionToToken.