I am having the situation needing to reset/update security context, maybe jwt. My project is microservice, spring cloud/oauth2/zuul…. The case is user's email has been stored in jwt once login. The email can be edited by one service, say identity provider; but, another service(notification) need to send user a email, which must be the newly updated one. The problem is notification can only rely on security context(details) email, that is out-of-date.
I am thinking
1. once identity service finished update email, it regenerate jwt
2. then, all services need to extract/reset security context
Any solution, hint, comment. Thanks
Related
I have an endpoint, which I want to protect using Oauth2 and spring boot. The users register on the website and after the successful payment, a token with specific expiry should be issued automatically and delivered to the user. The User can revoke the token in their panel and get a new token manually.
I don't want to use password grant type as it requires sending the username and password for each request. the authorization code grant type, requires the user to enter their credentials which doesn't fit my need for automatic generation of tokens after successful payment. I'm not sure if using client credentials grant type is a good idea for my need. I could use a new client for each new user. But this seems not right to me. But correct me if I'm wrong. any idea which oauth flow I should use?
You want to authenticate end-users with OAuth2? Use authorization-code (with PKCE).
In your statements, there seem to be a confusion between authorization-server (issues tokens) and resource-server (subscriptions are resources too in my opinion). Have a look at this article for OAuth2 refresher and spring resource-server security conf.
Also, it seems to be a one-to-one relation between access-token and payed subscription. This is probably a mistake: access-token should be short lived (like a few minutes). Are your subscriptions that short?
I see two options here:
have your authorization-server add a private claim with subscription status to JWT access-token (or introspection details) and check this claim value in spring-security expressions (#PreAuthorize("..."))
configure a custom authentication converter in spring security which calls a #Repository to read subscription status in database, based on identity contained in access-token
First solution is way more efficient (persisted subscription status is retrieved from DB only when a new access-token is issued) but requires your authorization-server to be flexible enough for you to add private claim with values from a web-service or a DB. I have a tutorial to do so in Keycloak. read it AFTER the article above.
please take this doubt away.
I have a Spring Boot application with spring security using JWT.
One question I always had is: How does Spring store the generated tokens?
Looking at the manager of my tomcat, I saw that this application has some open sessions, but it works exclusively with JWT. There is no point in it where I request to open a session.
So can I assume that Spring creates sessions to store the generated tokens?
you authenticate and then get issued a token from an issuer.
When this token is presented to a spring server, the resource server needs to do multiple validations before it will let you use the api.
A JWT is not encrypted, it is encoded, which means, everyone can see and read its contents. But it is also signed, so that you can not tamper with its contents without breaking the signage.
So the first thing a server does is to verify the signature to be sure it hasn't been temepered with. This can be done in multiple ways, one is to take the token and send it to the issuer and basically ask "hello is this token valid?" and the issuer says "YAY" or "NEY".
This generates a lot of extra network traffic if it needs to send jwts back and fourth for validation.
Since the signage of tokens are done with asymmetric encryption, the resource server can periodically (for instance each 30 mins) ask the issuer for the public key so it can verify the tokens itself without constantly needing to ask if they are valid or not.
This key is usually sent in a format called JWK (Json web key) and this key is then used to validate the integrity. If this validation passes it can trust the jwts content, and start checking the validation date, the scopes, and any extra claims in it etc.
And then if the token is valid has not expired, you can for instance choose to construct a UserDetails object from the data in the jwt.
As mentioned in the comments. If using JWTs you have no need for a session.
you should disable session creation.
You can read a lot more about sessions in this article here Spring Security Session
And here you can read about spring security Session Managment
I'm currently using OAuth with the password grant type to manage the security of my Spring Boot application. Now I want to store a login id which is queried by the auth server from the database when the client has successfully requested an access token.
To realize this I thought of passing it with the JWT. I used a custom TokenEnhancer in combination with a TokenChain to add the additional login id, which works fine. My problem is that I couldn't find a way, other than parsing the token myself, to get that login id.
Another, but a very bad solution could be to just pass it as authority.
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'm trying to integrate Facebook OAuth2 authentication with my own OAuth2 server. Just to be clear the scenario is the following:
I have a OAuth2 Server that is responsible for authenticating our users. I implemented a custom AuthenticationProvider that checks for the credentials provided and builds a UserDetails object if successful.
I also have a rest-api that is also a ResourceServer (runs in a different application). So users after being authenticated they can access our rest-api providing therefore the token.
The token information is shared using JDBC.
Everything works fine as expected, but now I want to add external authentication providers such as Facebook.
My question is: what's the best way to do this? What's the expected flow? From the top of my head I would imagine something like:
User authenticates with facebook
Facebook provides a token
User sends the token to our OAuth2 server
I check the token validity with facebook
I authenticate the user using the authentication provider
The server gets back to the user with a new token issued by my OAuth2 server which the user will use from now on to ask for resources
Is this right? If so, how can I send the facebook token to my OAuth2 server? Is there some kind of standard? Should I make up new parameters for that? For instance I will be needing some way to differentiate facebook authentications from user/password ones.
Am I suppose to use my own AuthenticationProvider to validate this facebook user? It seems strange then return a UserDetails object that doesn't have a password...
Also, how to register users and auto log them in? Do I have to expose an endpoint of my own or is there some OAuth2 magic for that as well?
Any thoughts?
Facebook has some very good documentation on this with the correct flow and how you should handle the process.
https://developers.facebook.com/docs/facebook-login/manually-build-a-login-flow/v2.2
You are on the right track, and I think the facebook documentation should help clear up any questions you may be having.
Additional Information is here:
https://developers.facebook.com/docs/facebook-login/v2.2