Opaque token bearer authorization

[KPrzychodzki]

Expected Behavior

• documentation suggesting how to tackle opaque token bearer configuration in authorization server setup
• indication of future code solution or clear explanation that it is left to our implementations
• in a perfect world - available out of the box and easily customisable bean bridging current gap

Current Behavior
Projects documentation indicates only how to configure jwt self-contained token bearers: https://docs.spring.io/spring-authorization-server/docs/current/reference/html/guides/how-to-userinfo.html

Similar configuration using opaque token seems to provide only one instance of OpaqueTokenIntrospector that would be available out of the box which as far as I can tell would work only if all the bearer token internal introspection calls used the same credentials (i.e. server had only one client using opaque token bearer). No clear indication of intended use of available classes in authorization server.

Context

1. I assume no changes to other functionalities i.e. the way introspection endpoint works, which potentially could be a way to work it around in an altogether different fashion
2. The only available in the framework implementations of above interface are SpringOpaqueTokenIntrospector/NimbusOpaqueTokenIntrospector (they seem to operate in similar fashion) with:
   2.1 First constructor (with injected client and secret) imposing constraint on what introspection can retrieve (i.e. only tokens associated with this specific client) - that's the only provided bean in resource server’s OAuth2ResourceServerOpaqueTokenConfiguration
   2.2 The other one (with rest template) - has an issue of how to retrieve necessary data (i.e. authorization details)
   2.2.1 but even having some handle there is an issue how to pass it around in an clear and concise fashion
   2.2.2 i.e. if one was to force using client_id parameter in the request like framework does elsewhere
3. Like said earlier - resource server documentation https://docs.spring.io/spring-security/reference/servlet/oauth2/resource-server/opaque-token.html#oauth2resourceserver-opaque-minimaldependencies does not capture whole complexity present in this use case as in naive approach every time opaque token bearer would be sent - it potentially would regard different client, thus in default implementation of introspection endpoint - different authorization would have to be sent with the request to introspection endpoint

[jgrandja]

Duplicate of gh-1101

[KPrzychodzki]

@jgrandja Just to confirm that I got it right - despite the fact without opaque token bearer authorization /userinfo cannot operate (for this type of tokens) it is left to us to implement it, is that right?

[jgrandja]

@KPrzychodzki

opaque token bearer authorization /userinfo cannot operate (for this type of tokens) it is left to us to implement it, is that right

No. Opaque tokens are supported by the /userinfo endpoint - OidcUserInfoAuthenticationProvider will work for either a JwtAuthenticationToken or BearerTokenAuthentication