Skip to content

Allow consent step to modify the stored OAuth2Authorization #2003

@OrangeDog

Description

@OrangeDog

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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions