Expected Behavior

I want to customize my authorization request in several ways for my multi-tenant application.

  • I want to change my provider URLs dynamically based on which tenant the user is trying to login to, redirecting them to a specific Azure Active Directory tenant based on what has been configured for the tenant in my own application.
  • I want to add the AAD tenant ID into the request attributes so that I can validate it against the JWT claims that come back, but I only want to do this for users logging in with Azure, and not any other provider.

The DefaultOAuth2AuthorizationRequestResolver otherwise works exactly how I would like it to so I'd like to just override these pieces. The authorizationRequestCustomizer seems like the ideal place to do so.

Ideally, I would be able to see the original request here so I can extract the necessary information and make these adjustments. I also want some way of determining which OAuth client registration is being used.

Current Behavior

Currently, only the builder is passed in. I can't extract any information out of this builder (I guess I could build it, extract, and then rebuild) but this only gets me some of the information I need.

Edit: Actually, I can't build it, extract and then rebuild because this causes an error trying to resolve the templated authorization URI. On the other hand, I can't easily work out that which client registration is being hit here without building it so I don't know that I am hitting Azure and that I need to supply the tenantId. Providing a getAttributes on the builder, like the getParameters, would be one way to help with this. For the moment, I will have to use some other kind of templating that doesn't trigger the built in templating and then manually replace it myself.

Context

Currently, I plan to copy and paste the entirety of DefaultOAuth2AuthorizationRequestResolver, adjust the customizer to make the request available, and then do the above. This workaround is not ideal because I then will need to keep my copy in sync with the upstream.

I am happy to raise a PR if this proposal is accepted.

Comment From: rupert-madden-abbott

On reflection I am closing this because I think it is not a good request.

The additional details I wish to persist are really related to the provider, and not the request itself. Instead I did the following:

  • In the oauth configuration properties, I added templated variables for the pieces I wanted to make dynamic (e.g. tenant ID)
  • Created a scheme for a "dynamic" client registration ID that was a combination of a statically registered ID (e.g. microsoft) and some dynamic ID (e.g. the ID of the account the user wants to login to)
  • Wrapped the in-memory client registration repository and intercepted the dynamic registration ID. Loaded the static configuration from the in-memory implementation and then added in dynamic information as needed based on the dynamic component of the ID.
  • Since the client registration ID is persisted in the authorisation request, the same dynamic elements are reloaded when the authorisation response comes back.

As a result, customising the OAuth2AuthorizationRequestResolver was not necessary.