As I understood correctly, from few resources like RemoteJWT Cache TTL,
Spring cached the JWK set in Resource Server for minimising the remote call to Authorisation Server for token verification to each API call. And Spring have default TTL for that is 5 mins, which we can increase as well.
However I've some queries on same:
What happens if user successfully logged out from client application and hit the resource server API with same JWT token and from Resources Server end TTL doesn't expired yet. Does they still able to access API.
Please correct me if my understanding is wrong and also give your thought on same. And if good resource on that, please do share. Thanks!
Related
I have implemented a spring boot application which does authentication and authorization using Spring OAuth2.
I am using JDBC token store to main the token issued to the client for performing Custom claim verification and some other user status verification during application run-time.
The question is, since i had used traditional JSESSIONID with CSRF token, i cannot find any advantage with the new OAuth standards because after login i would store the user details in the session and retrieve it whenever needed similarly for OAuth i store the User details in the JWT token itself and decode the token every time to get the user information, also i need to hit the database anyway for custom claim verification such as JTI verification .
Everyone says JWT is for stateless application but with JDBC token store i'm holding all the token that is issued to each client. Also there is an additional overhead to purge the expired token which will be done automatically with Session. Also i'm using refresh token as the way to implement session timeout.
Therefore can anyone explain me, when should i use JSESSIONID and when to use JWT ? My application is running on AWS architecture.
From my experience, cookie-based authentication sufficiently complicates scaling and load-balancing. If you have authenticated via the first service replica, your cookie will be not appliable to another replica, cause all sessions are stored in memory. So, if you want to scale your service in the future, session-based authentication can make things much more complex.
I have two authorization server application ( spring boot 2.0.5 ).
The two authorization server application are similaire
When a user ask for a token, spring will register a session for that specific user and give back a token, with that token you can access to the resource of application 1 but you can't access to the resource of application 2.
My question is if there is a way to share the same security context in addion when you generate token from application 1 you can use to access of application 2 resource
What you can do is to make your applications stateless when it comes to security.
What does it mean?
Spring Security will no longer generate a session for a new logged in user. When the user logs in, you will issue him a token (e.g. JWT). Each time when the user accesses secured content, he/she will have to provide a token and your applications will verify that token with a public or private key (depending on which type of token encryption you will use - symmetric or asymmetric). In the end, you will not need to share anything, if both of your applications have same keys to verify incoming tokens.
Some tips:
A token you send upon each request to access secured resources is called "access token". Make it expirable and make it short lived (like 15 mins). Why? This token cannot be immediately invalidated unlike session which can be simply deleted. In case if someone hijacks it, it will be still able to access secured resources.
Since your "access token" is short lived, it would be annoying for a user to logs in every 15 minutes. To prolong its life, you can have another type of token called "refresh token" that can be stored in some database. This token can be immediately invalidated by simply deleting it from the database. Therefore, if someone even hijacks it, user will be able to revoke it and the hijacker will not be able to prolong his session.
References: Stateless authentication with JWT
We are also facing similar problem.
For web pages we are using SSO which cache token in clientContext and using Authorization-server-1
For making call to API-1 we are using token generated by Authorization-server-2. In this case we have create another session bean for clientContext and that is caching token (having its own oauth2RestTemplate and clientCredientialResource)
This is two legged scenario
We doing research, how to use three legged scenario for calling web/rest service, but we were not able to do so, as access token retrieval is two step process (using authorization code) and call back will execute the whole method again and not continue from line after call to rest api
I was creating my own oauth2 server with SSO enabled for Google and Facebook. I found this example https://github.com/spring-guides/tut-spring-boot-oauth2 to be very useful and I was able to make my oauth2 server expandable after several tweaks.
For session storage, I used redis and everything seems to be working with the spring magics.
However I encountered a session problem when implementing logout. According to single sign on best practice, when a user logout from one client, all other clients with the same session from the auth server should also be logged out. So I added an endpoint for each client to invoke upon successful login to register it's name based on the user session from the auth server. However I noticed that each time I refresh the page on my client web app, I get a new session from the auth server. As a result, each time when I try to logout, the session associated with all registered clients will always become the old one.
I've been searching for solutions online but no luck yet. It would be greatly appreciated if someone could help me with this issue.
TL;DR version:
I implemented an oauth2 server with SSO enabled for Facebook with Spring Boot. After I successfully logged in with my Facebook account, I can see my client web app resources. Every time I refresh the page, I see a new session gets created from the oauth2 server and it gets stored in the redis storage and all the old sessions are kept in the storage as well.
UPDATE
It seems that all the new sessions are generated by anonymous users each time I refresh the page.
Ok after some digging, it turns out that anonymous user by Spring Boot is not much different from unauthenticated users, according to this doc https://docs.spring.io/spring-security/site/docs/current/reference/html/anonymous.html.
It makes sense that every time I refresh page a new session would generate. My problem was that I wasn't using the correct session ID when registering client app upon successful user authentication. Therefore I override "SavedRequestAwareAuthenticationSuccessHandler.java" file so that I can obtain client_id from the request parameter and then register the correct session ID obtained from the Authentication object to this client ID.
So we have an authentication server where the UI application gets the access token and then it communicate with API server, it's all good. Now we are building a third application which needs SSO to authenticate the same user and that is fine too.
However, there are scenarios where this third application needs to use some resources on the API server which, from my understanding, we need to get a token from auth server using client-id/secret and then send the request with the access token. This seems ok too, however I am not sure how API server is going to authorise that token (a hint on this would be great).
But the main problem is we want this request to be sent on behalf of the user. This is because API server needs to audit all user's activities. How can we achieve this using Spring Boot/OAuth2 and JWT Token?
I went through documentation and I know about #EnableOauth2Sso #EnableAuthorisationServer etc. but this scenario is not clear and I'm not even sure it's been implemented in Spring or not.
If there is no implementation for this scenario, what do you recommend? Any experience you have had on this, can you please share?
Your API server plays the role of a Resource Server. There is an annotation designed for that purpose: #EnableResourceServer. Your client app then will consume this resource using the handy OAuth2RestTemplate.
There are two approaches to properly configure the Resource Server and get this working:
Have the public key directly in your resource server app: this way when the client app try to use a token provided by the authorization server to get a resource from the Resource Server, this will verify if the token is valid by itself.
Configure the resource server to ask the authorization server if a given access token is valid and depending of the response it will allow or decline to get the resource.
I have posted a sample app on github using the first approach. There you can see the interaction between the Authorization Server, the Client and the Resource Server, as well as all the configurations you need for this implementation. Hope it helps you.
So I currently have this POC that I'm tinkering right now. I was thinking if it was possible that I can implement a Spring oAuth2 with JWT with a Authorization Server and a Resource Server both in different projects?
Flow goes like this User gets a token or passes through the Authorization Server and as long as he has the token and it's not expired he can make requests on the resource server.
I think that is the usual way to implement that. You have one authorization service providing tokens, either itself is backed by a database containing user information or maybe is asking another user service if the credentials are valid. The returned tokens can be used to make authorized request against the resource service(s).
Maybe take a look at the grant flow here.