You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
At the moment, this bundle implements the underlying library using JWTs. The authentication mechanism checks if a token is revoked through an AccessTokenRepositoryInterface and requires a UserInterface for the doAuthenticate() and createToken() methods. Part the of point, as far as I see it, for using JWTs is that their validation is encapsulated within themselves. Anyone with a public key can verify the token. This means that on remote resource servers, one can validate a token without having to proxy the auth server for introspection unless explicitly necessary (this of course makes a short TTL very important).
If your auth and resource servers are one-and-the-same (as the library/bundle appears to have been designed with in mind), then JWTs are just unnecessarily verbose. If you're going to access the Token Repository to check for manual revocation, why not just pass around the opaque token ID from the start?
All in all, I propose the bundle have 2 authenticators: a JWT authenticator without a revocation check and an opaque authenticator with a revocation check.
The bundle could stand to have a default TokenUser that just takes the sub and aud claims. Throw that right next to the NullUser.
The text was updated successfully, but these errors were encountered:
At the moment, this bundle implements the underlying library using JWTs. The authentication mechanism checks if a token is revoked through an
AccessTokenRepositoryInterface
and requires aUserInterface
for thedoAuthenticate()
andcreateToken()
methods. Part the of point, as far as I see it, for using JWTs is that their validation is encapsulated within themselves. Anyone with a public key can verify the token. This means that on remote resource servers, one can validate a token without having to proxy the auth server for introspection unless explicitly necessary (this of course makes a short TTL very important).If your auth and resource servers are one-and-the-same (as the library/bundle appears to have been designed with in mind), then JWTs are just unnecessarily verbose. If you're going to access the Token Repository to check for manual revocation, why not just pass around the opaque token ID from the start?
All in all, I propose the bundle have 2 authenticators: a JWT authenticator without a revocation check and an opaque authenticator with a revocation check.
The bundle could stand to have a default TokenUser that just takes the
sub
andaud
claims. Throw that right next to the NullUser.The text was updated successfully, but these errors were encountered: