Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

question: what is the use case for 'use_jwt_access_token' #478

Closed
pbfteambox opened this issue Oct 21, 2014 · 4 comments
Closed

question: what is the use case for 'use_jwt_access_token' #478

pbfteambox opened this issue Oct 21, 2014 · 4 comments

Comments

@pbfteambox
Copy link
Contributor

Hi,

I am trying to setup an oauth2/openidconnect server using the library. Everything works fine exectp when I turn the setting 'use_jwt_access_token' on.

I was under the impression that this setting was needed for openid, but I am obviously mistaken. However I don't quite understand the use case for this setting.

Under what circumstances is the server supposed to create an JWT Bearer ? (if any).

Best regards,

Patrick.

@bshaffer
Copy link
Owner

Thanks for the reminder - I need to update the documentation to the new naming conventions. But this refers to the server issuing JWT Tokens as Access Tokens, previously called Crypto Tokens - http://bshaffer.github.io/oauth2-server-php-docs/overview/crypto-tokens/

@pbfteambox
Copy link
Contributor Author

Actually I have read the documentation. But I still don't get in what situation one needs a JWT Token.

Do you have examples at hand of services that would need this feature ?

Also, is it desirable to create JWTToken for all case where an access token would be generated ?

Best regards,

Patrick.

@bshaffer
Copy link
Owner

you can use JWT Access Tokens if you have distributed systems, and need to validate a token's authenticity by more than one party without having to make a network call.

For instance, a token is granted by the Authorization Server. That token is a JSON Web Token signed by the Authorization Server's private key. The Resource Servers (where API calls are made) are spread out all over the world, running multiple applications. As long as the Resource Servers have the Authorization Server's public key, which does not need to be secured, they can validate the tokens quickly without any network calls. The tokens don't even need to be persisted.

It's an enterprisey use case, but is very useful for distributed systems.

@pbfteambox
Copy link
Contributor Author

Ok thanks for that little bit of information. This is what was missing from the doc page (which is otherwise complete), for me!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants