I am using laravel/passport password_grant for authentication. The whole generating access_token and refresh_token process is working fine. Now I am trying to use laravel passport token events to revoke old tokens.
I referred to this post for the process -
https://laracasts.com/discuss/channels/laravel/laravel-passport-revoke-and-prune-event-listener-is-not-doing-anything
This works... But when refreshing an access token using the previously provided refresh token, a new access token is being created and also a new refresh token being is created. Eventually, while revoking the old access token, the old, not expired refresh token also gets revoked.
But I think, the refresh token must be revoked only when it has expired.
And also when I remove the EventListeners from the App\Providers\EventServiceProvider $listen array, the revoking mechanism still works.
It's like even pulling out the plug the light bulb is still on.
How to solve this issue? Or am I wrong with the concept somewhere?
But when refreshing an access token using the previously provided refresh token, a new access token is being created and also a new refresh token being is created.
That's basically what makes refresh tokens prevent MITM attacks (to some extent). If someone intercepts your communication and finds your access token, they can impersonate you for as long as it lives. But if they intercept your request to refreshing your tokens, only one of you (the user and the attacker) can use it because it's revoked once used. If you get to use it first, it becomes useless to them. If they use it first, you'll be logged out because your old tokens will be revoked. If they can intercept all your requests - and keep finding your new access tokens, you need to reconsider your security setup.
From RFC6749 section 1.5. Refresh Token under Figure 2: Refreshing an Expired Access Token:
(H) The authorization server authenticates the client and validates
the refresh token, and if valid, issues a new access token (and,
optionally, a new refresh token).
Related
There is API on Laravel, which uses Laravel Passport for authentication. All worked well with the default settings. Then we decided to change the lifetime of the access token to 1 day and 1 month accordingly. It caused a problem with the refresh token.
Example: Access token is expired and the app sends the refresh token request to API. Then the app loses internet connection and can't get a new token. (Server sends new tokens but the app is unavailable). After the internet connection returned, the app sends a new refresh request but get 401. So apps need to get new code from API to authenticate the user. I don't think it's a good idea to force the user to login every day.
Any suggestions? Maybe there is some way like "handshake" to solve that problem? I mean refresh token only after confirmation the app got new tokens.
If I correctly understand your question, you're saying that you initially have an Access Token1, Refresh Token1 pair, and when the Access Token1 expired you try to request a new Access Token using the Refresh Token1.
Now, for some reason, you fail to receive this new Access Token2, Refresh Token2 pair, so what does the user do?. Well, you see this from the Consumer's point of view. If you see the same scenario from the Oauth2 Server's point of view.
The Server does not know if you failed to receive the token or you received it and failed to save. The server's job was to generate a new access token based on your valid refresh token. And as soon as it creates a new access token, it invalidates the old refresh token. This is the standard Oauth2 implementation.
You may try to make it so that the Old refresh token is not immediately revoked on new access token generation. But this introduces a possibility of replay attacks.
Hence, The standard practice is to have the User log-in again.
If I have a single page web application with a Laravel back end, my best option for authentication seems to be Passport with a Password Grant authentication flow. In Passport, this returns an access token and a refresh token.
For security, I would like to issue a short lived access token and refresh it when it expires. However, all the available information about using OAuth with a Javascript application says "don't make your refresh token accessible to the front end" because it's long-lived and can be used by others to generate new access tokens.
For example:
A Single-Page Application (normally implementing Implicit Flow) should
not ever receive a Refresh Token. A Refresh Token is essentially a
user credential that allows a user to remain authenticated
indefinitely. This sensitive information should be stored securely and
not exposed client-side in a browser.
Does this mean that a browser-based SPA cannot use refresh tokens and must, therefore, only issue access tokens that expire after a reasonable "session" length, forcing the user to log in again afterwards?
Otherwise, is there a suitable way to implement short-lifespan access tokens and refresh tokens in a Laravel Passport app with Password Grant authentication, while maintaining good security?
There is no harm in storing refresh token, as they can be used to get another access token after the access token(short lived as you mentioned) expires which create a good user experience.
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
I'm using the VSTS REST API. I use the refresh token, as instructed, to refresh the access token. This morning, the refresh tokens stopped working. Do they expire? If the access token and refresh token have both expired, how do I proceed? I can't find anything on this.
For reference: https://www.visualstudio.com/en-us/docs/integrate/get-started/auth/oauth#refresh-an-expired-access-token
Yes, the refresh token will be expired, you need to send request to re-authorize to get access token and refresh token again (your previous steps to authorize).
The previous access token and refresh token have been expired after get new access token.
I manage the team that implements this flow. The answer from #starain is correct and this flow is described in detail in the OAuth 2 specification. Your observation that the refresh token is invalidated so frequently #scottndecker is not consistent with the implementation. A refresh token in our system has a default lifetime of one year. The token can also be invalidated manually by users. We obviously must honor the user's right to revoke a previously granted authorization. If you want to share some more information we can certainly look into this behavior.
Seems that when the auth.token expires (after one hour), the auth.refreshtoken become invalid too? What is the auth.refreshtoken purpose then? When I decode the auth.refreshtoken on jwt.io, it should expire sometime in 2020. (Now it's 2019).
While the auth.token is valid, I can refresh and get a new token. So is the idea that I should setup a job that refreshes the token within one hour?
The documentation claims:
If a user's access token expires, you can use the refresh token acquired in the authorization flow to get a new access token. This process is similar to the original process for exchanging the authorization code for an access token and refresh token.