I’m tasked with doing research on authentication in an upcoming project at work.
I’ve played with a free Auth0 for some time and it seems great but I have some reservations my proposed workflow.
I realize one of the benefits of presenting JWT tokens to a protected resource is removing the need to contact authentication server on each request, but how does one deal with claims that can update between requests? (roles, first/last name, etc.)
Currently my frontend is treating the id token as proof of authentication only (not reading any of the claims presented in it) and by using the access token, my API retrieves a full user profile + roles, using the Management API to do so.
My concern is the documented rate limits of the Management API as each request to my API in this scheme will invoke a call to the Management API. Initially, there will be a very limited set of users (~10 concurrently), but I fear of getting rate throttled as the user base scales.
Are my concerns valid and if so, is JWT authentication perhaps not the route to go for my authentication/authorization needs?
Using JWT for authorization is a design choice with tradeoffs. On one hand, like you said, you are relieved from having to call the authorization server on each request (specially when the authorization server is not part of your application) to verify it. On the other hand, it can contain possibly stale data (from the time it was issued).
Very rarely a system needs updated information up to the last minute, so a sensible expiration time is the usual solution to this problem. E.g. you given the token a duration of one hour, and decide that you are OK knowing that role changes might take up to one hour to propagate.
If this doesn’t work for you because of specific constraints, then you’ll have to look up the information on every API request. But most likely you don’t need to do this for every piece of information. E.g. if the user name is not updated until the next hour, you might be OK with that, but you might want authorization information to be always retrieved on every API access (again, this is a potentially expensive decision which will have to be carefully weighted).
Like you said, Management API v2 is definitely not designed for this kind of scenarios. So any information that you require to be retrieved on every request (like roles) might be better stored on the application side.