Centralized authorization – via token or endpoint?

Firstly, I want to clarify the title. After spending a few weeks now tackling centralized identity I have found a lot of differing opinions and implementation of authorization (permissions). Mainly, there seems to be 2 ways I see it done

  • Store roles, and sometimes even strict permissions, in the access token (or some token associated with whatever protocol you are using). The upsides are ease of distributing this data to the client and resource, and security. The downsides are a potentially large token, and immutability of JWTs cause potentially out-of-date information.
  • Provide a centralized authorization server, or simply use endpoints on the identity server itself to serve specific authorization information, kind of like /userinfo but for authorization information. The upsides of this are up-to-date information and a clear separation of concerns. The downsides are a lot of calls to this endpoint, the fewest being one call per request as far as I can tell.

I see Auth0 allows a way to update token data on the fly (permissions, avatar, etc.) which is really convenient, however what are the downsides of using JWTs this way? I am confused as to why these protocols (OpenIdConnect, etc.) do not implement some way to force a token refresh, and thus a refresh of claims. I may be overthinking this, but what if a reference token was used, and we marked it as out-of-date? I mean, if we can mark a token as revoked then surely we can use some trick to mark it as stale? The client then would have default logic in this scenario to use its still-valid refresh token to receive a new access token. I feel like the utility of this whole system is really brought down by the fact that refreshing isn’t supported. Even if it was a separate permissions token, is this a valid idea? It just seems much more convenient than the latter.

For the second point, when using separate authorization and calling and endpoint for this info there are a few problems too. While I don’t know how PolicyServer’s paid version works, the OSS version uses this methodology. My problem with it is that the overhead of an http request is added to almost every page load, button click, etc. Using a refreshing JWT theoretically sounds like a nice way to only force a refresh when claims information is changed for a specific user only. In addition to this, basically every client and resource will need to know this claims information. While the resource itself should use authorization information, the client is still going to need to dynamically show/hide content based on this info as well. How do we easily share this information without having both the resource and client(s) request this information on every action? In PolicyServer’s demo, it’s just a bare client using authorization information from the API endpoint, there is no resource involved, probably because it was a complicated issue.

Is my idea in the first point of marking a reference token as stale practical? It would take a lot of work and would have to override existing interfaces both on the server and client. However, I just cannot see a dedicated authorization endpoint as a possibility given the concerns above. I’m still perplexed as to why none of these protocols have an easy way to refresh claims information after specific actions.

Go to Source
Author: perustaja