Storing refresh token
See original GitHub issueI managed to implement the authentication flow (while still waiting for https://github.com/microsoftgraph/msgraph-sdk-java-auth/issues/14) and now I wonder what I should store long-term so that the users do not have to re-authenticate once their session is gone. The refresh token alone is not enough, I guess, we also need the account, the scopes are good to remember too just like the expiry.
The TokenCache
is a candidate (why doesn’t ITokenCache
implement Serializable
?) even though I’d prefer not to store some serialized 3rd party object in the DB that might change at any time. But the silent flow sample also uses the IAuthenticationResult
that’s held in the session. I might extract the account from the TokenCache
but IConfidentialClientApplication.tokenCache()
only returns a ITokenCache
and not the TokenCache
so I’d have to blindly cast it.
tl;dr Before I stitch together a whacky solution - is there an official thing to store away? I’d like to actually use the refresh tokens long-term to not annoy the users with re-authentication. The most reliable and straight forward thing that comes to my mind without digging too deep is to code custom wrappers for TokenCache
and IAuthenticationResult
to store them away.
Cheers
Issue Analytics
- State:
- Created 3 years ago
- Comments:5 (2 by maintainers)
@Avery-Dunn thanks for the thorough reply! I missed the other constructor on SilentParameters. Now it’s down to using my own
ITokenCacheAccessAspect
.I’ll open some issues in the msal4j repo.
Thanks again and have some nice holidays!
@black-snow For the accounts, it depends on how you’re using the cache
SilentParameters
.SilentParameters
has a builder for scopes+account as well as just scopes, and if not provided an account then it will still work if each cache has one account.getAccounts()
method, find the account you need from the returned set, and then do the silent calls with that account. If you’re loading up the client app and have a persistently stored cache, then you just need to set the cache when starting up the app like in this sample, after which you can callgetAccounts()
to get them all from that cacheFor the token cache, most of this was all designed before my time here, but I believe the reason that most of the internals of the token cache aren’t public is because they shouldn’t ever need to be adjusted manually, refreshing is taken care of by the library’s silent calls, and I think pretty much everything in the token cache is retrievable in some way:
AbstractClientApplicationBase.getAccounts()
, and an account should be inAuthenticationResult
objects returned in every token request (both silent requests and specific flows)AuthenticationResult
object returned in the initial token request, or in theAuthenticationResult
object returned when making a silent token request (this will have either the cached tokens, or the refreshed tokens if the originals expired)