I’ve implemented OAuth login providers and a JWT provider and calling the ConvertSessionToToken service to obtain an access token cookie/value. The application is a Nuxt universal app, and we are using an IAuthRepository. It’s all working fine at the moment, and have moved the ConvertSessionToToken call to the server as a Nuxt plugin, so SSR works correctly.
Ideally, we would like to have short lived tokens and a refresh token, but the ConvertSessionToToken() does not currently return a RefreshToken. Obviously, it’s still possible for the users session to change i.e. a users account to be locked out, role changes etc. We would prefer not to have to get users to re-authenticate with the OAuth provider frequently.
Is there a reason why RefreshTokens aren’t implemented for the OAuthProvider use cases?
The RefreshToken is only returned by the /auth Service which can’t be used to retrieve new JWT’s beyond its expiry that it was issued with at authentication. Once the Refresh Token expires the User needs to re-authenticate to get a new one. You don’t want RefreshTokens to be able to extend themselves as anyone who gains access to it, can extend it indefinitely without ever needing to authenticate.
You can update ExpireRefreshTokensIn if you want to increase the lifetime of Refresh Tokens, but it does default to 365 days.
I see you’re retrieving the JWT token via converting the session, not during authentication. I’ll add an option to return it there as well.
Hmm, after further reading, I’ve come to the conclusion that what I was asking for is frowned upon for SPA’s (as you were probably hinting at in your 1st reply). It would essentially give a way to perform similar to an Oauth Implicit Flow, but with a refresh token (which shouldn’t be part of that flow).
I’m guessing instead I can shorten the access tokens expiry but look into doing a silent renew against the original OAuth provider (in an iframe) when either close to expiry (as is done in OIDC Token Client) or after initial page load. Though that would cause issues with generating SSR version of a logged in user, so will be some jank when they first load the page.
For now, I think I’m going to stick with sessions and cookies, as this seems like a better solution.
You can still use stateless JWT cookies, by default ConvertSessionToToken returns a secure HTTP-only “ss-tok” cookie containing the JWT so it doesn’t need a session persisted on the server.