-
Notifications
You must be signed in to change notification settings - Fork 1.3k
Description
Expected Behavior
As the only point of user interaction in the OAuth flow, there should be a way to capture additional custom data that is associated with the current authorisation process, and can be used in future processing.
Current Behavior
Nothing from the OAuth2AuthorizationConsentAuthenticationToken
nor the OAuth2AuthorizationConsent
(both of which are customisable) is stored in the OAuth2Authorization
.
The only solution is a complete copy-paste of the OAuth2AuthorizationConsentAuthenticationProvider
(and/or device code equivalent) and its non-public dependencies (#1290) to add e.g. a single line.
OAuth2Authorization updatedAuthorization = OAuth2Authorization.from(authorization)
.token(authorizationCode)
+ .attribute("CONSENT_REQUEST", authorizationConsentAuthentication)
.attributes((attrs) -> attrs.remove(OAuth2ParameterNames.STATE))
.build();
Context
In my specific case I have a scope that requires additional user qualification. This is taken as an additional parameter from the consent page, and used to add an additional scope (equally, one could have the consent just add to the scope parameter).
This was easily done previously by extending a UserApprovalHandler
and overriding updateAfterApproval
, which allowed arbitrary changes to the request with e.g. different scopes.
The standard allows authorization servers to ignore the requested scope, and return a narrower, wider, or even completely different scope if they wish. Again it's a minor edit to allow that:
Set<String> authorizedScopes = new HashSet<>(authorizationConsentAuthentication.getScopes());
- if (!requestedScopes.containsAll(authorizedScopes)) {
- throwError(OAuth2ErrorCodes.INVALID_SCOPE, OAuth2ParameterNames.SCOPE, authorizationConsentAuthentication,
- registeredClient, authorizationRequest);
- }
Or you could provide a validator interface instead with that as the default implementation, as with other providers.