Token strategy for multiple resources

Hi,

This is a bit of an open ended question, but I was wondering how people have architected their solution to deal platforms dealing with many applications talking to many resource servers using OIDC? I have read this article (https://www.pingidentity.com/en/company/blog/posts/2019/oauth2-access-token-multiple-resources-usage-strategies.html) which suggests the primary options are:

  1. Single access token / single audience to be used across all resources
  2. Single Access Token with Multiple Audiences (not sure this is supported in Okta)
  3. Multiple Access Tokens (one custom auth server per service - one token per service)

Option 1 would appear to be the obvious choice, but I can see a situation where Claims/Scopes and other auth server config will become hard to manager when handling many resource server requirements.

I’d appreciate any input into this discussion.

Thanks

Your right about option 2, although the token exchange RFC may address that specific requirement down the line.

For option 3 you have the added benefit of being able to control the token lifespans granularly for each service