Enable forward request (like ForwardSuccessHandler) in OAuth2AuthorizationCodeGrantFilter

[jjfraney-cg]

Expected Behavior

The developer can override the redirect strategy in configuration to for OAuth2AuthorizationCodeGrantFilter to issue request forward into the existing web context (i.e., a relative path) at the end of authentication.

Current Behavior

Current behavior enables only redirects. The redirect strategy in OAuth2AuthorizationCodeGrantFilter cannot be overridden by configuration.

The active request is the authorization server's callback after a successful grant. Within the context of that request, this filter will send a request to the token URI to obtain an access token. After completion, the filter responds with a redirect to the authorization server. The target of the redirect is the original incoming request that triggered the authentication.

Context

How has this issue affected you?
I have a client whose custom authorization server does not respond to this last redirect. My application doesn't get the callback to the business level request.

What are you trying to accomplish?

My client is a SmartOnFhir implementation. I'm implementing a 'launch' use case. To initiate a launch, the SmartOnFhir implementation sends an opaque token as a query parameter to an endpoint in my application. I'm using the oauth2client configuration. In my controller, I call OAuth2AuthorizedClientProvider.authenticate to start the authentication flow. SmartOnFhir will send confidential data within the access token after successful authentication. My business logic has to obtain and decode the access token. This is why I require a callup to my controller. If the redirect worked, things would work.

What other alternatives have you considered?
I'm using the oauth2client configuration. Maybe I should try the oauth2login configuration. Using oauth2login, I believe I can easily use the ForwardAuthenticationSuccessHandler without a problem. I'm not wild about this approach: I'm not that interested in user data in my application, and I have to figure out how to disable the login page (if necessary) because there is really only one authorization provider by the requirement of SmartOnFhir.

Are you aware of any workarounds?
No, only to copy the OAuth2AuthorizationCodeGrantFilter into my project, make a change within it to support forward, and add it to the security filter change before the existing original filter.

[sjohnr]

Hi @jjfraney-cg, thanks for reaching out and welcome to the project!

I think it would be plausible to add an AuthenticationSuccessHandler to this filter to enable customization, if a redirect truly doesn't make sense in certain cases. Before we discuss that however, I am curious about your use case if you wouldn't mind going into a bit more detail. In particular:

After completion, the filter responds with a redirect to the authorization server. The target of the redirect is the original incoming request that triggered the authentication.

I wouldn't expect the "redirect to the authorization server" to be happening in this context as OAuth2AuthorizationCodeGrantFilter is processing the response from the authorization server. The next sentence seems to state what I would expect to happen, so could you perhaps describe the steps of the flow to clarify?

I call OAuth2AuthorizedClientProvider.authenticate to start the authentication flow

Are you saying that you trigger the authorization_code flow from the client by directly calling the provider? Does that mean you are not using the OAuth2AuthorizationRequestRedirectFilter?

[jjfraney-cg]

Thanks for quick response!

After completion, the filter responds with a redirect to the authorization server. The target of the redirect is the original incoming request that triggered the authentication.

I wouldn't expect the "redirect to the authorization server" to be happening in this context as OAuth2AuthorizationCodeGrantFilter is processing the response from the authorization server.

Right. It's not a redirect to the authorization server. That language is incorrect. I'm sorry for being sloppy.

I call OAuth2AuthorizedClientProvider.authenticate to start the authentication flow

Are you saying that you trigger the authorization_code flow from the client by directly calling the provider? Does that mean you are not using the OAuth2AuthorizationRequestRedirectFilter?

I am using the OAuth2AuthorizationRequestRedirectFIlter. It handles a ClientAuthorizationRequiredException from my controller. My controller delegates the decision to throw that exception to OAuth2AuthorizedClient.authenticate. I am learning and reconsidering that design. I would prefer not to throw ClientAuthorizationRequiredException directly because I sense it is an internal implementation artifact of Spring Security.

Maybe your question is: "Why not use webclient to trigger the authorization_code flow?". In case that's your question: Because of the nature of the SmartOnFhir specification. An http request to the resource server doesn't make sense until after the token is in hand.

[sjohnr]

Sadly, I'm not familiar with those specifications. However, I did glance at app-launch which seems to match what you're describing. The opaque token you're referring to is the launch parameter, correct?

SmartOnFhir will send confidential data within the access token after successful authentication. My business logic has to obtain and decode the access token. This is why I require a callup to my controller. If the redirect worked, things would work.

Once the authorization_code flow is completed back on the client, you will have access to the token without needing to decode it yourself. So I don't think you need to use a forward to accomplish this.

For example, assuming you have a client registration called fhir-client:

@GetMapping(value = "/app/launch")
public SomeResource getResourceFromFhirServer(
		@RegisteredOAuth2AuthorizedClient("fhir-client")
				OAuth2AuthorizedClient authorizedClient) {
	// Use the token from authorizedClient and/or make request to backend...
}

If there's no access token yet, you'll be directed through the authorization_code flow automatically. You'll be redirected back to /app/launch once the client is authorized.

An http request to the resource server doesn't make sense until after the token is in hand.

Would the above code accomplish this, or am I still missing a piece of the puzzle?

[jjfraney-cg]

You're not missing any piece of this puzzle. You found the fhir spec.

That annotation rings the bell.

Thanks.

[jjfraney-cg]

Assume different end users are driving a unique app-launch request. Shouldn't each have an opportunity to grant authorization? It appears that after the first session drives an authorization grant, the following sessions reuse the token. Am I expecting wrongly?

[sjohnr]

@jjfraney-cg, it's hard to say without a bit more context. Do you mean that you log out of the client application, and log in with a different user, but when you go through the authorization code flow, you get a new token without consent? If so, that's typically because the authorization server still has a session available as whatever user first logged in and provided consent. Or are you speaking of something else?

[jjfraney-cg]

I'm watching the servlet session JSESSIONID and the token. The JSESSIONID is different per call, but the token is the same. So, either I have the notion of a session wrong, or I have to convince Spring to create a new token per session.

My app doesn't have user context. All anonymous. No login/logout.

I think oauth2login may be better than oauth2client configuration. Would oauth2login provide a new token after consent per login?

oauth2login configuration gives me these challenges:

• I don't know how to disable the automated login screen that comes with oauth2login. I don't need it as there is only a single provider. I'd like to hardwire the login sequence to use the single provider's authorization server.
• I couldn't customize the authorization requests. The configuration didn't use my authorization resolver. I have to add custom properties.
• There would not be a logout event, as far as I know. I have not seen a logout in the Fhir spec. I would have to follow up with the development team of Fhir to confirm.

[sjohnr]

Hi @jjfraney-cg, I think we're getting into the territory of questions that would probably be best for stack overflow, as my intention was to discover whether the use case involved here would require changes to the framework. So far, it doesn't appear that they do, but it sounds like we might need to prove that by working through some of the questions you've brought up. If you wouldn't mind opening a stack overflow question with these points and linking to it here, I can work with you on getting an answer.

My app doesn't have user context. All anonymous. No login/logout.

I think oauth2login may be better than oauth2client configuration.

What I can say for certain is that you are on the right track here. Having an anonymous user doesn't work well with http.oauth2Client() because the authorized clients are tied to the principal name. So in your case, it would always be something like "anonymousUser", which isn't what you want.

[jjfraney-cg]

Thank you.

https://stackoverflow.com/questions/71828258/how-can-i-require-consent-for-each-unique-anonymous-user-with-spring-security-oa

[sjohnr]

@jjfraney-cg I have added an answer. Once you've reviewed it, let's discuss how that impacts this issue and whether it really makes sense to add forwards as stated in the expected behavior:

The developer can override the redirect strategy in configuration to for OAuth2AuthorizationCodeGrantFilter to issue request forward into the existing web context (i.e., a relative path) at the end of authentication.