Support for "Curity style" Phantom Tokens

[thomasdarimont]

Curity supports a token translation pattern called "Phantom Token" that allows an API gateway to exchange an opaque access token for a JWT-based access token by using the token introspection endpoint with the request header "Accept: application/jwt".
The Curity server will respond with the JWT string of the access token.

Although not standardized, this, IMHO, is a neat integration pattern that allows exposing opaque tokens to external token consumers, while using enriched tokens for internal backend services behind an API gateway.

Could mod_auth_openidc provide similar capabilities?

I'm thinking of something along the lines:

• Apache httpd could serve as the "API-Gateway" via mod_auth_openidc and mod_proxy
• mod_auth_openidc is used to secure a route like /api and uses mod_proxy to forward the request to a backend
• mod_auth_openidc could use the token introspection endpoint to validate an opaque access token
• mod_auth_openidc could add the request header Accept: application/jwt to the token introspection endpoint
• if response status = 200 then mod_auth_openidc would read the returned JWT from the token introspection response body, if status 204 -> not authenticated (according to Curity)
• If a JWT was returned in the response, replace the original token in the Authorization Header with the returned JWT access token
• Optionally provide a caching option to spare repeated checks with the same token.

There are some implementations for API gateways and HTTP servers for this pattern already, e.g., for nginx: https://curity.io/resources/learn/nginx-phantom-token-module/.

As a side note:
Keycloak can also be used to leverage the Phantom Pattern via Lightweight Access Tokens (minimal JWT access tokens) as it supports the Accept: application/jwt header in the token response. When generating the internal token, Keycloak can add additional information to the token.
One caveat with Keycloak: currently, Keycloak returns the JWT as a "jwt" claim in the regular token introspection response. However, I'll raise an issue to make this configurable so that it returns a proper JWT in the response body.
With a small custom Keycloak extension that behaves as expected by the Phantom Token pattern, I can successfully use the Nginx-based Phantom Token integration.

Would something like this make sense for mod_auth_openidc as well?

[zandbelt]

This OAuth 2 .0 use case is covered by using mod_oauth2 combined with mod_sts , in an architecturally proper way rather than (ab-)using the token introspection endpoint for this; FWIW: mod_auth_openidc is an OpenID Connect RP module and it supports propagating claims in a (self-)signed JWT, see: https://github.com/OpenIDC/mod_auth_openidc/blob/v2.4.18.1/auth_openidc.conf#L862-L870

[thomasdarimont]

Thanks for the quick response Hans! I think https://github.com/OpenIDC/mod_sts with the token-introspection approach might do the trick. I'll give this a try.

[zandbelt]

just to make sure: that would be "token exchange", instead of "token introspection"