• caglararli@hotmail.com
  • 05386281520

OIDC identity token authentication using JWKS instead of token_introspection

Çağlar Arlı      -    43 Views

OIDC identity token authentication using JWKS instead of token_introspection

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?