Provide Cookie implementation of AuthorizationRequestRepository

[jgrandja]

We should consider providing a Cookie based implementation of AuthorizationRequestRepository.

[afrancoc2000]

Hi @jgrandja, How many votes do you need?

[jgrandja]

Hi @afrancoc2000. There is no specific number of votes we target but this one has enough to start prioritizing. However, we are pretty jammed with higher priority tasks that need to get into the upcoming 5.2 release so this one will take lower priority. It would be helpful if someone from the community would contribute a PR for this as I believe it would be fairly trivial. Would you be interested in submitting a PR?

[jgrandja]

@afrancoc2000 Can you provide details on why you require a cookie implementation of AuthorizationRequestRepository? I'd like to understand your use case before we proceed with any work.

Anyone else interested in this feature, I'd like to hear from you as well and your use case so I can understand the reasoning for needing such an implementation.

[afrancoc2000]

Sure the reason is microservices applications, today the best way of handling this type of apps is making them stateless so any app can respond to any request.

The authorization can be easily saved and restored from a jwt cookie thats better than having a session because for sessions I need an extra component like a redis cache, that means more infrastructure, more points of failure and the posiblility of conflicts between sessions, problems that could be easily solved by replacing a couple lines of code.

Also that allows me to link an external frontend more easily just by passing the jwt cookie that is a standard in the industry.

I would love to help I was looking at the example of @naturalprogrammer in this links: link 1, link 2 but found out that storing the OAuth2AuthorizationRequest is not enough and I would prefer to do the implementation with a jwt cookie saving and restoring the security context, haven't got till there yet.

[jgrandja]

@afrancoc2000 The AuthorizationRequestRepository is responsible for persisting the OAuth2AuthorizationRequest as part of the authorization_code grant flow. Please see Authorization Request for more details.

It does not save a Jwt as it seems that is your understanding?

The authorization can be easily saved and restored from a jwt cookie

Please correct me if I'm misunderstanding your comments?

[fnaeem78]

I was hoping to use the cookie based approach, because I am trying to use spring-oidc to authenticate to multiple providers, but wanted to do it in a seemless manner. If I implement a cookie-base request repository, and maybe write a cookie from javascript, when the response comes back, it will have a request in the cookie format and will let the flow go to my endpoint instead of intercepting it and returning me a the oidc login page.

[Gittenburg]

Would simply saving the serialized OAuth2AuthorizationRequest to a cookie and deserializing it on load be save? Or does leaking / allowing tampering of the OAuth2AuthorizationRequest introduce security issues?

[rwinch]

We would not want to perform Java serialization/deserialization as that can lead to a lot of different types of attacks. The cookie would need to be written as a String that did not allow attackers to control the Java objects that were being created.

[Gittenburg]

Alright, is there a need to encrypt or sign the cookie?

[rwinch]

I cannot think of any reason to do this. The user can make changes to the cookie, but it only impacts their own security and not much different than tampering with redirect URLs sent from the server.

[Gittenburg]

If we want to avoid (de)serialization, how do we deal with attributes and additionalParameters of OAuth2AuthorizationRequest? Because both can contain java.lang.Object?

[rwinch]

You would need to use Spring's Conversion APIs to convert it to/from a String. You would avoid including the type information in the String as that is what is used for deserialization attacks.

[milanov]

Any updates on this issue?

[jgrandja]

@milanov There are no updates. Quite honestly, I'm reconsidering on NOT providing this feature. There are a few vulnerabilities around Cookie tampering so I'm hesitant to proceed with this feature.

If the main motivation for this feature is to achieve statelessness, then providing a Cookie based implementation of AuthorizationRequestRepository will not be sufficient enough. Access tokens are associated with OAuth2AuthorizedClient, which are stored via OAuth2AuthorizedClientService. The current implementations are in-memory and HttpSession - so this would need to be addressed to achieved statelessness. There are other areas that would need to be addressed as well, e.g. SecurityContext etc.

The key point I want to emphasize is that storing secret/private information on the server is the most secure way and transporting secret/private information over secure and/or un-secure channels is NOT the most secure in certain scenarios.

I'd like to hear more from the community on the motivation for this feature, in case I'm missing something.

[milanov]

In our case the motivation is exactly statelessness. If login is attempted on one of our instances, then performed at an IdP and the user is redirected back, we'll have to resort to special measures to ensure that the same instance handles the request, in order to have matching state and complete the login process.

I guess we can use a shared storage-backed AuthorizationRequestRepository (for example in Redis), which we can implement ourselves. On the other hand, I assume that this is a fairly common case in a multi-instance environment (as indicated by the number of votes as well), and so a standard solution could exist out-of-the-box.

[jgrandja]

@milanov

I guess we can use a shared storage-backed AuthorizationRequestRepository (for example in Redis)

This can be achieved today with the help of Spring Session.

Please see gh-7889 for complete details on how to setup and configure to support application clustering.

[jgrandja]

This feature will not be implemented for the reasons mentioned in this comment. If an application requires this, it would be fairly trivial to implement a custom AuthorizationRequestRepository, please see gh-8621.