Expected Behavior

Many of us are working on integrating Apple login using Spring Security as a client. While struggling with the limitations of the basic OAuth2ClientProperties configuration, I discovered an intriguing statement in RFC 6749. According to sections 1.3.1 and 1.7, any method that achieves redirection is permissible. This suggests that transmitting state and code via HTTP POST as form data, not just as HTTP GET query parameters, is also acceptable.

Although other transmission methods are possible, I propose to extend the default configuration to support HTTP POST with form data, similar to how it currently only allows HTTP GET with query parameters.

Alternatively, introducing a customizer interface would be beneficial. It would enable free parsing of the state and authorization code from the ServerRequest, providing developers with greater flexibility.

Current Behavior

Currently, there are two main issues:

  • WebSessionOAuth2ServerAuthorizationRequestRepository.removeAuthorizationRequest() raises an exception because the query parameter does not have a value for state.
  • ServerOAuth2AuthorizationCodeAuthenticationTokenConverter.convertResponse() raises an exception because the query parameter does not have a value for state.

Comment From: krezovic

You can implement your own ServerAuthenticationConverter and ServerAuthorizationRequestRepository<OAuth2AuthorizationRequest> and pass them to http security chain configuration. Their implementation is quite simple and extending it in any other way is just waste of time and adds unnecessary complexity.

Comment From: sjohnr

@minkichoe thanks for reaching out! I'm always intrigued to hear about efforts to integrate with Apple login as it seems like a challenging task in any case, and I haven't had the chance to do it myself.

I propose to extend the default configuration to support HTTP POST with form data, similar to how it currently only allows HTTP GET with query parameters.

I'm not sure I follow what you're suggesting specifically here. Are you suggesting an enhancement to WebSessionOAuth2ServerAuthorizationRequestRepository, Spring Boot configuration properties, or something else?

Alternatively, introducing a customizer interface would be beneficial. It would enable free parsing of the state and authorization code from the ServerRequest, providing developers with greater flexibility.

As @krezovic suggested above, you can provide your own ServerAuthorizationRequestRepository<OAuth2AuthorizationRequest>. I would argue this interface is not difficult to implement, and you can freely customize how you resolve the state parameter among other things. I think keeping the existing implementation simple is preferable. Is there a reason you don't feel this is an appropriate way to solve your use case?

Comment From: minkichoe

Thank you for your responses. As @krezovic mentioned, implementing ServerAuthorizationRequestRepository is straightforward. I have also completed Apple login by creating necessary implementations, including the mentioned interface.

My initial hope was to make it easier for others to implement Apple login in the future, even if they are unaware of the need to implement these interfaces. Although I didn't suggest it in my original post, I thought it would have been beneficial to include HTTP methods and payload types (e.g., form data, JSON, query params) in the Spring Boot Configuration properties for enhanced usability.

However, I understand that increasing complexity in code maintenance is a concern and that this solution may not solve everything. Therefore, I agree with keeping the implementation simple. To achieve my goal of assisting others, I plan to change my approach. Instead of raising a PR, I'll write a blog post or similar to easily share my explanations and implementations with those who are interested.

Comment From: sjohnr

To achieve my goal of assisting others, I plan to change my approach. Instead of raising a PR, I'll write a blog post or similar to easily share my explanations and implementations with those who are interested.

I think that's a great idea! Thanks. Please feel free to share a link here when you complete it so that others can find it. When you've completed that, I'd love to review it and I can open any issues if I find anything I feel should have been provided by the framework to make things easier for you.

I'll go ahead and close this issue for now, since we've decided against a related change in the framework at this time.