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?
Refresh tokens are the credentials that can be used to acquire new access tokens. The lifetime of a refresh token is much longer compared to the lifetime of an access token. Refresh tokens can also expire but are quiet long-lived.
Storing refresh tokens via silent authentication involves sending a request to the identity server to get an access token whenever there is an API request or during page refresh. If your session still remains, the identity provider will return a valid token. Otherwise, it redirects you to the login page.
Refresh tokens are something handled entirely on the backend, and not connected to a user's session. For example: set up a cron job, query for tokens about to expire, make POST requests to refresh them. Passport doesn't get involved in this process, because its separate from authentication.
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).
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With