I'm a beginner in Spring Boot and I set up OAuth2 and all work well with inMemory () data.
I'm trying to store the Token in DB but I want the client to stay in memory because I will always use a single client for this application
so i created the necessary tables using schema.sql i see that only the oauth_access_token and oauth_refresh_token tables that will be used and when i make a request to request a token the system returns the old one if it is still valid and a new one if not(this is good but..). For this reason I have difficulty understanding how the system can know that a token is expired or not? (knowing that I do not define JWT token or any other specific type of token explicitly)
The token in this scenario is an instance of class DefaultOAuth2AccessToken which has field
expiration
which takes care of expiry of a token. Object of this class is serialized so that it can be stored in database.Upon deserialization values are populated in respective fields and below method is invoked to check for expiry.
public boolean isExpired() {
return this.expiration != null && this.expiration.before(new Date());
}
The class DefaultTokenServices has createAccessToken() method to create token.
just go and have a look at these classes to see the working.
Thanks for your answer
After some research in the documentation i can now understand how the token is validated.
the token (DefaultOAuth2AccessToken) is stored as a serialized object in the DB and it will be retrieved from the database to validate expiration date , and many other operation ...
Related
How Can I Bind userType with jwt token??
because in the frontend needs to do some operations with type of user(hide some menus if userType is different)
in laravel.. Does it possible?
The way Laravel (and you most likely using https://github.com/tymondesigns/jwt-auth), is that the JWT should probably not carry user types or really other kind of user information than maybe a name or an id. After the token is generated, you are supposed to query another endpoint that will return the user information that you are looking for.
So essentially, what you want is 2 routes, let's say:
POST /auth/login
POST /auth/me
To the first route, you are supposed to provide the username and password, to which you'll get a token if credentials are correct. Then, you take the token you were just given, and call the second endpoint, which will return all user information you might want or need. You don't specify which kind of frontend you are using, but here's an example with Nuxt.js's Auth module: https://auth.nuxtjs.org/providers/laravel-jwt/
I am playing around with building a custom Oauth2/OpenID library, and is having thoughts about validating the tokens.
I am using only JWT for all token types (Access, Refresh & ID), but I am thinking; How would the resource server validate ex. the access token, and make sure it is only access tokens from the issuer being accepted, and not refresh or ID tokens, since they would also be valid, hence they come from the same trusted issuer?
Likewise, how would make sure, the token sent with a refresh grant, is not just an valid access token, since it would also be verified...
I know an easy fix would be just making a custom claim, describing what kind of token it is, or using different signatures for each, but is there a "right" way of doing it?
One way to separate the ID token from the Access token is by looking at the typ claim in the JWT-header.
Some IdentityProviders uses the at+jwt typ to indicate that the token is an access token that follows certain rules. But this is not a mandatory thing to follow.
{
"typ":"at+JWT",
"alg":"RS256",
"kid":"RjEwOwOA"
}
Otherwise they can look at the claims inside the token to determine if it is an access or ID-token. The token-signature itself can't be used to determine the token type.
You can read more about the standard for access token here and here
Refresh and reference tokens are typically not in a JWT format, instead they are more like a random string.
I successfully implemented JWT as a authentication filter in my web application. When user's login is successful, I am creating a new JWT and assigning userName in the sub field of JWT.
In the subsequent request's I am using userName in the JWT sub field to identify the user. But what if the user changes his userName in the update section of the application. Is there way, I can update the value of sub field in JWT ?
What I am thinking!
I am thinking of getting the existing JWT in the RestController and after updating the userName, I will update the JWT with new userName and again send back to the client. Is this fine or is there a better approach?
I think I should refresh the token after update is done and send back the refreshed token back to client.
#RequestMapping( value = "/account", method = RequestMethod.POST )
public ResponseEntity<?> updateAccount( #RequestBody UserDetailsBean userDetailsBean, HttpServletRequest request,
HttpServletResponse response )
{
try
{
UserAccessDetails accessDetails = getLoggedInUser();
UserDetailsBean updatedUserBean = userService.updateAccount(userDetailsBean, accessDetails);
// send updated jwt incase of mobile number update by user
response.addHeader(SecurityConstants.HEADER_STRING,
SecurityConstants.TOKEN_PREFIX + refreshJWT(updatedUserBean.getMobileNumber()));
return buildResponse(updatedUserBean);
}
catch( DataException e )
{
return buildError(e);
}
}
private String refreshJWT( String subject )
{
return Jwts.builder().setSubject((subject))
.setExpiration(new Date(System.currentTimeMillis() + EXPIRATION_TIME))
.signWith(SignatureAlgorithm.HS512, SecurityConstants.SECRET).compact();
}
This is working. If anyone has a cleaner and industry standard approach please specify.
If you allow your users to change their usernames, they should also have an immutable user id that can be used to identify any data or activity associated with a given user. Otherwise, any time a user changes his or her name, you will either lose the ability to audit the user's past actions or you will have to update all references to that username in the database. What's worse is if there are references to an old username in the database and another user takes that username -- now you have data from one user now being associated with another due to incorrect handling of user identification.
Now with that said, the sub claim should contain this immutable user id. You can create a separate claim for the mutable username. When a username is changed, you now only need to change a single field in the database (assuming that only the users table references this mutable username). You could then use the refresh token retrieve a new token that would contain the latest username that could then be used by your API as needed.
Using this approach, you should be careful to only use the username claim for display purposes, not for identifying the logged in user due to the fact that it is mutable. The sub claim containing the user id would serve the purpose of identifying a user.
It is also important to note that this solution requires no special logic for "updating the sub claim." You would be using the same logic that you're already using to generate a token for a supplied refresh token.
I know those token spring generates a UUID formatted string. One of my concerns is that it's not really "unique"; it is possible for the UUID to create a token exactly the same as a previous one (of course the odds are VERY small but still possible).
I'm using a database to store my user's token and I'm not sure if Spring checks if the token already exists before creating one in the database?
My second question is : Is it possible to create my own token instead of the UUID format, I'd like to have a more "unique" token like the current timestamp with the user's ID and username and then hash everything and that will be my token instead of 49784c38-43b1-.....
I already have a custom TokenEnhancer that I use to add custom info when returning the token to the client but how can I create a custom token before saving it in my database?
Thanks for you help!
Your TokenEnhancer can use any format it likes for the token value. The custom value will be the one that goes in the ToeknStore (that is the prupose of a TokenEnhancer).
P.S. If you think there might be a clash between UUIDs I think you probably need to do some maths and think again.
When my authentication handler passes successfully (userId is taken from decrypted token) I want to add the userId somewhere to the current request object.
Later in the pipeline when the user is authenticated the authorization is executed and here I need the userId again because I have to disallow authenticated users manipulating data from other users having a certain userId.
What would be the best way to save temporarely the userId? Should I misuse the request.headers to add there the userId?
cmon Darrel...please don't re-invent the wheel ;)
The authentication handler outcome should be a ClaimsPrincipal (set it on HttpAuthenticationContext.Principal).
This way you make the user id available to an authorization filter - as well as ApiController.User.
HttpRequestMesssage.Properties. It is a dictionary designed for storing request scoped data.