More and more web applications are becoming stateless, so it should be possible to replace sessions with JWTs instead. For applications using OIDC as an authentication method, this means that JWTs are used in order to access an Authentication object.
Spring Security is already supporting JWT Authentication by configuring an Oauth2 Server, handy for API endpoints, but it would be great if this authorisation flow was compatible with OIDC, SAML and similar authentication methods as well.
See my post on Stackoverflow and how this was implemented in Spring Lemon: https://stackoverflow.com/questions/66352038/spring-security-oidc-and-jwt-instead-of-session https://dzone.com/articles/spring-security-5-oauth-20-login-and-signup-in-sta
Comment From: jzheaux
Thanks for the suggestion, @erlendfg.
I don't think I'm completely clear on what you are trying to achieve, though when you say:
replace sessions with JWTs instead ... but it would be great if this authorisation flow was compatible with OIDC, SAML and similar authentication methods as well.
Are you saying that you'd like, for example, Spring Security's OIDC support to emit a JWT that the browser can store in lieu of the session storing it?
Or, are you saying that you want to use the JWT as a session identifier?
If I've missed your point, perhaps you could offer a bit more detail about how you'd imagine Spring Security's OIDC support changing to accommodate your use case.
Comment From: erlendfg
By describing our use case shortly, I hope to clarify the issue.
Today our users are being authenticated by OIDC and we are using Spring Session to support clustered sessions. We have API users as well since we provide an API. Now we want to rewrite the Spring Boot application to become a React-based single page application (SPA). For the API part we will use Spring Oauth2 Resource Server for JWT validation. And this is exactly want we want for the end users as well — send JWTs between frontend and backend with information about claims (the information atored in Oauth2User).
If our authentication model was based on LDAP (username/password), we could easily implement a login endpoint to obtain a JWT. But Spring's OIDC client requires sessions, and there you have the problem.
Comment From: jzheaux
Thanks, @erlendfg, that's helpful.
There is a related discussion about some of the security implications of stateless OIDC starting with this comment. It's recommended that security information be stored server-side with the help of Spring Session.
If you are determined to store security information in the browser, though, please see #6374 where support for this would likely need to begin.
I'd be curious to see if @jgrandja has any additional insight.
Comment From: jgrandja
@erlendfg Spring Security's OpenID Connect support implements Authentication using the Authorization Code Flow. In this flow, the client is a confidential client and performs the authentication server-side. This is implemented per spec.
Based on your new requirements:
Now we want to rewrite the Spring Boot application to become a React-based single page application (SPA). For the API part we will use Spring Oauth2 Resource Server for JWT validation. And this is exactly want we want for the end users as well — send JWTs between frontend and backend with information about claims (the information atored in Oauth2User)
You need to implement OpenID Connect Authentication using the Implicit Flow. As per spec:
The Implicit Flow is mainly used by Clients implemented in a browser using a scripting language. The Access Token and ID Token are returned directly to the Client, which may expose them to the End-User and applications that have access to the End-User's User Agent. The Authorization Server does not perform Client Authentication.
The React SPA would need to implement the Implicit Flow. This would not be implemented by Spring Security.
I would not recommend the implicit flow since the token credentials are exposed through the browser and there are security implications to this approach.
As a side note, the referenced post (https://dzone.com/articles/spring-security-5-oauth-20-login-and-signup-in-sta) is a proprietary solution. Our goal is to implement to spec and custom solutions would need to be implemented in the consuming application, as demonstrated in the post.
I'm going to close this issue as OpenID Connect Implicit Flow is meant to be implemented by a scripting client NOT Spring Security.