Repository navigation
Replies: 2 comments 1 reply
|
I like the idea of using providers in general for OIDC extensions, but rather than leverage protocol mappers perhaps it might be better to have a concept of an OIDC extension provider? For things like DPoP it would be great if this could be added as some sort of pluggable provider. To the point that it would have been possible to add DPoP through a custom extension (not saying we should do DPoP as an extension, just saying that it should have been possible). OIDC lends itself pretty well to this kinda concept of being able to have extension providers. |
|
@dteleguin as you've mentioned, it is useful to change some logics during receiving a token request and sending back its response by some scheme like SPI providers. Just one idea for how to configure such providers is that we could change such providers by client policies. For example, if FAPI advanced security profile (requiring OAuth MTLS holder of key access token) is applied to a client, client policies change a default provider creating normal tokens to a custom provider that creates OAuth MTLS holder of key access token. |
|
Not quite sure I'm following. What do you mean by changing the default provider? Isn't it just about enabling an additional extension provider such as OAuth MTLS, or DPoP? |
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
In Keycloak, there are features that rely on modifying token contents. We have MTLS-HoK that adds
cnfsection to access + refresh tokens and introspection response; we will soon have DPoP that does the same plus ID tokens and token response (token_type=DPoP); we might have HTTPSig one day that would do something similar. For example, DPoP does the following for token response:and the following for access token:
Currently, all the token manipulations are hardcoded into TokenEndpoint / TokenManager. On the other hand, there is an existing mechanism that is suited for the same, namely protocol mappers (OIDCAccessTokenMapper, OIDCAccessTokenResponseMapper, OIDCIDTokenMapper, and eventually OIDCIntrospectionResponseMapper).
It would be nice if features like MTLS and DPoP could use protocol mappers as helpers. However, mappers need to be configured by the admin beforehand. Even if MTLS and DPoP manage to add their respective mappers programmatically, the admin could remove them by mistake. The proposal is to introduce the concept of system (implicit?) mappers, that would be different from the traditional mappers in the following aspects:
This way, system mappers won't have corresponding entries in PROTOCOL_MAPPER / PROTOCOL_MAPPER_CONFIG. Alternatively, we can keep just number 2 (invisibility) and let the software components like MTLS and DPoP set up the mappers programmatically. In this case, database entries will be created as usual.
The rationale behind this proposal is to allow reuse of the existing mechanisms and decouple token binding from TokenEndpoint / TokenManager (which already contain a fair amount of code), thus making the codebase more manageable.
@tnorimat @mposolda
All reactions