We are experiencing an issue in production which seems identical to when we restart our dev boxes and try to authenticate using the token that was generated with the previous instance of our SSO Spring Boot App and powered by Spring Authorization Server.
The error is: Wrong nonce
In production, it looks to occur when our SSO app scales up due to a user spike. We could see this happening at a point with high user activity and we would continually get logged out.
Now, of course we do not want all our active users to suddenly have invalid tokens just because a new instances of SSO is added.
This questions also relates to the currently unanswered, but much older question here: Can Spring Security OAuth2 Authorization Server scale horizontally?
Please advise. It is the number 1 most frustrating issue we are having in production right now and we are not quite sure how to proceed. We are not using any In-Memory implementations of classes.
2022-07-12 - Update: The question was asked "How are we storing the session?"
- We are storing OAuth2 authorizations, authorization consents and registered clients in MongoDb.
- We implemented OAuth2AuthorizationService, OAuth2AuthorizationConsentService and RegisteredClientRepository
CodePudding user response：
Spring Authorization Server is built on Spring Security (see docs Overview) and does require knowledge of Spring Security (see Getting Help).
In particular, you'll want to review the Authentication chapter of Spring Security documentation. Session management falls under this topic, and if you're using (for example) form login or something similar, you'll almost certainly want to add Spring Session to your server to manage distributed sessions.
You are also likely running into an issue on the client side if you are not managing sessions in a database, so once again looking into Spring Session for the client will help alleviate issues such as the nonce error you mentioned. You will also want to look into the OAuth2 Client documentation and review the core interfaces as you will need to be storing your client authorizations in a database as well.
CodePudding user response：
Steve writes a great response above already and I marked it as the answer.
To answer the title of this question: Yes, Spring Authorization Server can easily be scaled to include multiple instances without suffering from the original misconfiguration issue we were experiencing.
Spring Authorization Server does not have any magic tools to persist a session across instances. It is reliant on session management being configured correctly. We use Spring Session backed by MongoDb for our purpose.
Session validity best practices is probably something that should be addressed and whether some of them should have the same timeout values.
- Servlet session timeout
- Spring Session timeout (this overrides 1 when present)
- Remember me timeout
- Token timeout
We are still figuring out / playing with what these values should be and have found no document or article that speak of one best way of doing things.