search

thephpleague / oauth2-server

A spec compliant, secure by default PHP OAuth 2.0 Server
https://oauth2.thephpleague.com
MIT License
6.49k stars 1.12k forks source link

Opaque token support #1284

Closed alernety closed 2 years ago

alernety commented 2 years ago

Hello

I'm working on project where already implemented "Authorization code grant" + JWT with this library, but now my intention to transfer from JWT to opaque token. Is it possible to do with this library?

Sorry if it was already discussed, but I can't find the topic.

Sephster commented 2 years ago

Hello. Thanks for reaching out and no worries on posting something here. I need to get around to creating a discussion board at some point but for now, no worries posting in issues.

Yes it is possible to use a different token format if you wish. You would need to create a new token validator that implements the AuthorizationValidatorInterface and create a new response type that extends the AbstractResponseType. I think that is all you will need to do. Basically create something that can build your token, and something that can read it. Hope that helps!

ash-m commented 1 year ago

@Sephster Any reason to not have these classes as part of the library?

Sephster commented 1 year ago

Just not wanting to maintain too many things really. For the vast majority of users I think they are happy to use JWT and the library allows you to use something else if you wish with relative ease

ash-m commented 1 year ago

@Sephster So I opened an issue on the Symfony bundle implementation which currently performs a check by loading token data to an object and checking if it is revoked. It seems the current implementation's default works under the assumption the auth server and resource server are the same (or at least use shared token storage). Correct me if I'm wrong, but isn't part of the point of JWTs to make it's validation self-contained (given the public key). If you're going to be querying a storage backend anyway, what benefit does using JWTs offer?

Unless I am missing something, an opaque token should cut down the logic substantially: https://gist.github.com/ash-m/171bd3b17fe0a294d52c372ec46a7d25/revisions

Let me know if you see any problems with this. Or I could possibly start a PR to just add that as a validator, idk.

Sephster commented 1 year ago

We make no assumption that the auth server and resource server are one and the same. You could have these separate if you like and I believe some people do.

We don't currently support token introspection which would be more convenient for separation purposes but hope to in future.

As I've noted before, it is possible already for you to change the token type if you wish for your own implementation. We use interfaces throughout the lib to make adjustments like this possible but at this time, would be unlikely to merge this into the lib itself