0

This may be just an academic question, but I have been wondering about something, OK so for this purpose all we care about is AuthN, not AuthZ. Also, there are no users at all, just daemon-to-daemon communications.

So of course we're all used to the scheme where a client, that has been assigned an identity on an IDP, first uses its client_id & secret to fetch an identity token (could be a simple opaque token, not a signed JWT embedded with any claims) from an IDP. Then this client requests access to some resource and includes this token with the request. The resource then first validates the token with its own call to the IDP using the token_introspection endpoint, and assuming that passes then the resource performs some AuthZ function that is beyond the scope of what I want to discuss here before allowing the client to have access to the requested resource.

So what I just discussed is a common mechanism that daemon-to-daemon systems use, and it's worked fine, but what about this, where instead:

  1. Client uses its id & secret to request from the IDP a signed JWT, specifically an "access_token" containing claims of the client ID and a tenant ID of the IDP.

  2. Client requests access to a resource and includes this JWT as a bearer token.

  3. The resource doesn't need to make an external call to the IDP as the resource was provisioned with the IDP's JWKS data and can immediately read the JWT and see it as legitimate as it contains a client_id and the tenant ID (as long as the other usual claims for timing, etc) and the resource can validate the signature on the JWT belongs to the IDP configured as its JWKS server. At which point the resource can trust that the requestor IS the client ID in the JWT claim.

So thats it, I've yet to come across that type of deployment, seems like its secure and solid just like the other one with 1 exception that revocations aren't possible which could be mitigated by small-is expirations. Does what I described even have a name of its own? Or is it un use anywhere?

1
  • Token introspection is not required for JWT tokens. It is good to have it in case you want to check if they have been revoked, otherwise verifying their signature is enough. Token introspection is used for opaque tokens as there's no other way to verify their validity.
    – defalt
    Commented Feb 1 at 13:07

0

You must log in to answer this question.

Browse other questions tagged .