I'm working on a production-ready implementation o...

# http4k

[leonhardt]

I'm working on a production-ready implementation of OAuthPersistence to support OIDC, and I'd like to keep all values server-side in a single session. I was surprised to find that all the assign* methods on the OAuthPersistence interface don't have access to the request, so I wouldn't be able to retrieve a shared session to reference all the values together.

I could follow the pattern in the example here:
https://github.com/http4k/http4k-by-example/blob/master/src/main/kotlin/verysecuresystems/oauth/InMemoryOAuthPersistence.kt
and use separate cookies for each value, but that means effectively creating and managing a separate session for each OAuthPersistence value, which feels tedious and error-prone.

I noticed that in every place the assign* methods of OAuthPersistence are used (i.e. OAuthRedirectionFilter and OAuthCallback), the request is available in scope. Is there a good reason why the request isn't included in the assign* method signatures? Is there some design constraint or security consideration behind this, or would it make sense to add the request so a single session can be referenced to help manage this sensitive state server-side with a single session?

[dave]

The request is available to these functions:

fun assignToken(request: Request, redirect: Response, accessToken: AccessToken, idToken: IdToken? = null): Response

   fun retrieveToken(request: Request): AccessToken?

... which in a session-based environment should give you everything you need to make it work.

We've done this securely before, creating a JWT and setting it as a cookie in the "assignToken" function

[leonhardt]

Thanks @dave. That works great for assignToken. What I was really hoping for was a consistent pattern across all the assign* methods so I could keep CSRF, nonce, originalUri, and PKCE values server-side in the same session, rather than managing them individually with separate cookies.

Is there a particular reason these methods (assignCsrf, assignNonce, assignOriginalUri, assignPkce) don't also accept the request, like assignToken does? Maybe there's a design or security consideration I'm missing, but my plan was to avoid client-side storage for all these values.

[dave]

There's no technical reason why tbh, so you could PR it in so that there are 2 methods with one delegating to the other (which is deprecated). Giving people access to the request isn't going to hurt.

As for the security concerns, you might want to keep those factors separate to decrease interception risk, but apart from that I can't think of any tbh. (That being said, I'm not an authority on advanced security!)