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
I have discussed this feature request with the community.
Describe the background of your feature request
One of the options to pass the information about the authenticated and authorized subject to the upstream service availablel today is a built-in Security Token Service (STS), implemented by the jwt finalizer.
It allows exchanging any authentication information used by the client (tokens, cookies, etc) for a highly customizable JWT that the heimdall instance itself signs and provides the keys via the jwks endpoint to verify. Even that approach is useful for implementing edge-level access control architecture, it leads to transparency loss in the identity management flow as heimdall becomes a token issuer authority, which might be challenging or even unwanted in particular setups.
Describe your idea
To still have the above written functionality without heimdall being a central actor in the identity management flow, a new finalizer supporting the OAuth 2.0 Token Exchange protocol (RFC 8693) would be helpful. The finalizer type could be named e.g. oauth2_token_exchange.
Pros & Cons to be considered:
By making use of the OAuth 2.0 Token Exchange protocol, flexibility supported by the jwt finalizer (ability to define claims that end up in the new token) will be lost to some degree.
New tokens can be issued via a standard protocol established for that purpose.
That new finalizer can most probably only be used in combination with authenticators acting on OAuth2/OIDC protocol.
Hemdall is not a central actor in the identity management flow any more
Are there any workarounds or alternatives?
No
Version
v0.13.0-alpha
Additional Context
No response
The text was updated successfully, but these errors were encountered:
dadrus
changed the title
Support for OAuth 2.0 Token Exchange (RFC 8693) finalizer
Finalizer supporting OAuth 2.0 Token Exchange (RFC 8693)
Feb 15, 2024
There is an RFC draft for so called transactional tokens which closes the first con written in the description as contextual information can be passed down to the new token.
Preflight checklist
Describe the background of your feature request
One of the options to pass the information about the authenticated and authorized subject to the upstream service availablel today is a built-in Security Token Service (STS), implemented by the
jwt
finalizer.It allows exchanging any authentication information used by the client (tokens, cookies, etc) for a highly customizable JWT that the heimdall instance itself signs and provides the keys via the jwks endpoint to verify. Even that approach is useful for implementing edge-level access control architecture, it leads to transparency loss in the identity management flow as heimdall becomes a token issuer authority, which might be challenging or even unwanted in particular setups.
Describe your idea
To still have the above written functionality without heimdall being a central actor in the identity management flow, a new finalizer supporting the OAuth 2.0 Token Exchange protocol (RFC 8693) would be helpful. The finalizer type could be named e.g.
oauth2_token_exchange
.Pros & Cons to be considered:
jwt
finalizer (ability to define claims that end up in the new token) will be lost to some degree.Are there any workarounds or alternatives?
No
Version
v0.13.0-alpha
Additional Context
No response
The text was updated successfully, but these errors were encountered: