Spring-security: Provide Cookie implementation of AuthorizationRequestRepository

[jgrandja]

We should consider providing a Cookie based implementation of AuthorizationRequestRepository.

NOTE: This feature may be provided depending on user demand (votes). Please upvote if this is a feature you would like to see in Spring Security.

[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.