I want to disable the generated JWT token when the user logs out from the application and this needs to be done in back-end code. How can I disable the JSON Web Token (JWT) using the authentication server (SpringBoot)
Generally speaking, with JWTs you have an access token with a short duration (like 15 minutes) and a longer refresh token (30 days). You should store the refresh tokens that you've given out in a table and when the user logs out, flag the token as revoked and then when you give a new access token out, verify that the refresh token hasn't been revoked.
Related
How to revoke the access token and refresh token of the user as an admin user? while using JWT in Oauth2. is it recommended to store token in Database ?
If you want to be able to revoke tokens, then there is no other way but to keep some data in the database. You can either keep the concrete tokens, and mark them as revoked until they're expired, or you can keep an entry with clientID/userID and a timestamp, and do not accept tokens issued to that client/user, before the given timestamp.
If you want to be able to revoke access tokens, then you have to remember that all APIs, which consume that token, will have to call that database to check if the token was revoked or not. It is usually easier to have short lived access tokens (15 or even 5 minutes), and only deal with revoking the refresh token, as the RT is only used in your Authorization Server.
While Creation of an OAUTH token i came across different methods to create Access Token and Refresh Token, while Access Token has life of 30 mins and Refresh Token has lifespan of 100 days, there is no way to regenerate refresh token without providing credentials again i.e Username and Password.
Is there any way to regenerate refresh token without using credentials?
below are the attached resources the i read:
OAuth 2.0 with Service Now
Below are the steps we can generate access_token and refresh_token
https://developer.servicenow.com/blog.do?p=/post/inbound-oauth-auth-code-grant-flow-part-1/
create an endpoint for client access
https://docs.servicenow.com/bundle/paris-platform-administration/page/administer/security/task/t_CreateEndpointforExternalClients.html
Request parameters to get access_token and refresh_token
https://docs.servicenow.com/bundle/paris-platform-administration/page/administer/security/reference/r_OAuthAPIRequestParameters.html
these are the response we are getting
https://docs.servicenow.com/bundle/paris-platform-administration/page/administer/security/reference/r_OAuthAPIResponseParameters.html
There is not concept of regenerate token we can only do it buy increasing the token expiration time.
I believe you do not need username and password, just client ID and client secret is req'd to get the new access token
enter image description here
I am trying to implement Oauth2 with Jwt in my Application. One doubt I am having is why do I need to have lesser expiry time to access_token and a longer expiry time to refresh_token.
What I mean to say is I can have an access_token with a longer expiry time and I would protect access_token like I am protecting the refresh_token, there is no need to refresh_token only. Does that make sense?
So if I am ignoring refresh_token from my application, would I face any usability issue or security issue?
See RFC 6749:
1.5. Refresh Token
Refresh tokens are credentials used to obtain access tokens. Refresh
tokens are issued to the client by the authorization server and are
used to obtain a new access token when the current access token
becomes invalid or expires, or to obtain additional access tokens
with identical or narrower scope (access tokens may have a shorter
lifetime and fewer permissions than authorized by the resource
owner). Issuing a refresh token is optional at the discretion of the
authorization server. If the authorization server issues a refresh
token, it is included when issuing an access token (i.e., step (D) in
Figure 1).
A refresh token is a string representing the authorization granted to
the client by the resource owner. The string is usually opaque to
the client. The token denotes an identifier used to retrieve the
authorization information. Unlike access tokens, refresh tokens are
intended for use only with authorization servers and are never sent
to resource servers.
I am quite new to JWT based authentication. And im quite confused about the refresh token mechanism. In my case, I have designed my application as,
1. User will login to the application, and when the login is successful then it will go to the authentication server and sign a jwt and will pass it to the client.
2. And then the client will store the refresh token and the short lived token in the local storage
3. Once the resource server is called the token will be sent through the header. and will get validated.
My question is, in which point should we request another token using the refresh token mechanism. Should we check whether the short lived token is invlaid before sending the request to the resource server. or should we get a new token once the validation fails in resource server? or is there any better way to handle this?
A Refresh Token is a special kind of token that can be used to obtain a renewed access token —that allows accessing a protected resource— at any time.
Although Access Tokens can be renewed at any time using Refresh Tokens, they should be renewed when old ones have expired, or when getting access to a new resource for the first time. Refresh Tokens never expire OR have very long expiration time.
Implemented Django REST and authentication using JWT.
For JWT token we have to refresh it before it expire.
After expired JWT wont give new token.
For my mobile device I need to refresh the token every 10 mins (JWT_EXPIRATION_DELTA).
and if user is not active for more than 10 minutes, then I need to ask to login.
Is there any way that I can refresh the token even after JWT token expired. (we can limit the time to refresh as 2 day)
Whats the best way to handle this behavior in Mobile.
Thanks.
Refreshing tokens in django-rest-framework-jwt
The django-rest-framework-jwt (v. 1.11.0) does not support "Refresh Tokens" as described for example here. It only supports refreshing non-expired tokens; It makes easy to implement a sliding expiration window with width of JWT_EXPIRATION_DELTA. For example, with settings
'JWT_EXPIRATION_DELTA': datetime.timedelta(seconds=300),
'JWT_REFRESH_EXPIRATION_DELTA': datetime.timedelta(days=7),
user cannot be inactive for more than five minutes in order to stay logged in (docs).
Real Refresh Tokens, please?
It is possible to implement the "Refresh Tokens", which are very long lived ("never expiring") tokens, stored in a database, just like in conventional "HTTP Sessions & SessionIDs". This is actually already been implemented for the django-rest-framework-jwt in django-rest-framework-jwt-refresh-token. Another possibility is to use django-rest-framework-simplejwt which also implements the JWT with Access and Refresh Tokens (full example at Medium).
But.. why?
Compared to using only Access Token JWT's, using Refresh Tokens makes possible to revoke access after the Access Token is expired. Refesh Tokens make it possible to have very long ("lifetime of a mobile device") lasting tokens. One may ask why shouldn't you just stick with sessions (sessionid in a Cookie, and session data in database table), if you are creating collection of Refresh Tokens in a database, and accessing that. Using an Access token with expiration time of one hour will mean that database must be accessed once per hour (instead once per PUT/POST request when using "traditional" sessions). In addition, you gain all the usual benefits of JWT tokens (ease of use in microservice network, for example).
You can use refresh tokens, as defined in Oauth2.0
Refresh tokens are credentials used to obtain access tokens. Refresh
tokens are issued to the client by the authorization server and are
used to obtain a new access token when the current access token
becomes invalid or expires,
After a successful login, issue a refresh and an access token. While a access token expires shortly, a refresh token is long lived. Store it securely, and use it to issue new access tokens when the current one expires