Adding support to JWT based tokens

[AlmogBaku]

Instead of storing the tokens in the DB, we can generate JWT tokens with a unique hash and to deliver them to the user.
This method will reduce dramatically the calls to the DB, and will remove the need to remove old access-tokens.

[wcummings]

Is anyone working on this? I'd like to implement this but I want to make sure I'm not duplicating effort.

[turneliusz]

Hi @wcummings, do you have any progress on that? I would really love to use that feature

[wcummings]

Nothing substantial, haven't had much time recently.

[d-tylczynski-foodpanda]

@Ener-Getick I see that FriendsOfSymfony/oauth2-php#79 has been merged, is it possible to make a release with it plus release of the bundle?

[Spomky]

The merged PR does not allow to implement JWT based access tokens but JWT Bearer token grant type (RFC7521 and RFC7523).

[GuilhemN]

@d-tylczynski-foodpanda I released a new version of https://github.com/FriendsOfSymfony/oauth2-php but it doesn't solve this issue as pointed by @Spomky

[dkarlovi]

Example usage of JWT as an access token shows you can use it as a pre-validation of the access token, no need to use it as "full" JWT.

Example:

1. I use ?access_token=a, you need to do a full dispatch, database query etc to figure out my token is invalid, I get 401.
2. I then use ?access_token=b, you need to do a full dispatch, database query etc to figure out my token is invalid, I get 401.
3. etc

This type of denial-of-service attack allows the attacker to force the app to always miss its cache and do (expensive) database lookups only to reject the request.

With JWT, the access token itself needs to be valid first before it's validated against the database which can be done way before the request gets to our app (for example, Varnish could probably do it).

[leroy0211]

This is a very old ticket but I don's storing your access_tokens in a database is bad idea. What are you going to do when a token needs to be refreshed? You still need all the same scopes from the previous access_token to determine the scopes of the new access_token.

However, I agree with @dkarlovi. When accessing a resource when using a JWT token it will reduce the amount of Database access, since the validation of a JWT token can be determined without Database access.

Only when creating, refreshing, revoking or exchanging a token, then database access is required.

[stof]

@leroy0211 you will still need to reach the DB when validating the OAuth token. Otherwise, revoking does not work (when you revoke a token, the JWT token stays valid, so revocation won't be effective if you only rely on getting a valid JWT token)

[leroy0211]

Usually access_tokens don't need to be revoked due to their short lifetime. The refresh_tokens are the one you want to revoke. Also it doesn't really makes sense to revoke access_tokens, because server and client have something like a "contract" which both agreed on for that short lifetime. It would be unnecessary to revoke that "contract".

But if you need to revoke access_tokens and reduce database access you can cache the access_tokens and test the validity on the cache. Which when revoked, the cache key wil be dropped. So next time the access_token wil be validated, the cache wont hit so the real database call wil be executed. This wil reduce database access a lot!

When also using Token introspection the same cached object can be used.