Repository navigation
Enable user authentication by presentation of an SD-JWT identity credential with OAuth 2.0 for First-Party Applications (FiPA) #38796
Replies: 5 comments 2 replies
|
There is a lot of conceptual and architectural decision to be taken with respect to this feature. We hereby invite the community to contribute with comments on this discussion. |
|
The first failing request will probably produce a LOGIN_ERROR event. We should make sure that we can differntiate those from "normal" LOGIN_ERRORS, as the former a "normal" expected event during the FiPA authentication and the later is an "exceptional" event. |
|
Thank you for pointing that out. It was very likely overlooked indeed. |
|
Reconsidering our intention not to embed OpenID4VP logic into Keycloak, due to purported complexity and the potential introduction of JSON Path and JSON schema dependencies, we noticed that this could actually be avoided by implementing a justified limited parsing of authorization responses. So we are equally exploring the idea of making Keycloak a full-fledged OpenID4VP verifier for user authentication via SD-JWT presentations, thereby discarding the foundation of OAuth 2.0 for First-Party Applications (FiPA). We'd appreciate opinions about one or the other approach. |
|
Hello @Captain-P-Goldfish @dominikschlosser - Following the brief discussion on this point in the OAuth SIG meeting, find our POC implementation on this alternative strategy here: main...adorsys:keycloak-oid4vc:sdjwt-user-auth-on-oid4vp. All is contained in a single commit, including a documentation and comprehensive tests to navigate the implementation choices. While the version of the OpenID4VP standard considered is Draft 20, I believe things won't change that much with more recent versions. |
|
Are there any specifications related to this? This is not the kinda flow we would want to invent on our end and support in Keycloak in a proprietary way. Another way of doing this is to allow exchange the SD-JWT for an access token directly, for example https://datatracker.ietf.org/doc/html/rfc7521#section-6.3 or https://oauth.net/2/token-exchange/. Combined with what I'm proposing here #42197 |
|
@stianst @mposolda @francis-pouatcha @IngridPuppet @tdiesler In my opinion, the natural way to integrate VP into Keycloak at first is using A potential next step would be to integrate it into the login flow itself, the same way as As for the trust anchors used to verify credentials, the newly introduced |
Uh oh!
There was an error while loading. Please reload this page.
Motivation
With recent developments, Keycloak can serve as an OID4VCI issuer, issuing a verifiable credential for parties to validate the identity of a user. Enabling users to log in to Keycloak by presenting that same credential is a valid use case, and one that is gaining traction.
The SD-JWT format for verifiable credentials is certainly one of the most supported currently. In our use case at adorsys, we specifically want to exchange an SD-JWT identity credential for an access token, so as to maintain legacy systems operable. By this, we mean Keycloak is not intended to implement the OID4VP peer protocol to OID4VCI for verifying presentations, which, given its complexity, would have probably justified the addition of some dependencies. Instead, Keycloak is intended to verify SD-JWT presentations, i.e., with the presence of a Key Binding JWT (KB-JWT), and eventually return an access token.
For reference, these issues enabled Keycloak to run this SD-JWT verification:
Proposal
Our proposal is to delegate OID4VP interaction with a user wallet to an external client, which in turn, runs this SD-JWT against access token exchange with Keycloak. Though OAuth 2.0 for First-Party Applications (FiPA) is primarily thought for providing native login experience, we believe it remains sufficiently agnostic of the authentication means to enable its API-only conceptual foundation to be leveraged for this SD-JWT authentication. The FiPA flow is particularly helpful in preventing replayed presentations.
SD-JWT authentication may be achieved by implementing an SD-JWT authenticator for FiPA for these reasons:
Here is a comprehensive sequential diagram of the scenario:
%%{init: {'sequence': {'actorMargin': 150}}}%% sequenceDiagram participant C as FiPA Client participant K as Keycloak C->>K: Authorization Challenge Request Note over C,K: {client_id, client_secret, auth_flow: "sdjwt-flow"} K-->>C: Authorization Error Response Note over C,K: 400: {auth_session, auth_metadata: {vct, nonce, aud, required_claims}} C->>K: Authorization Challenge Request Note over C,K: {client_id, client_secret, auth_flow: "sdjwt-flow", auth_session, sdjwt_token} K-->>C: Authorization Code Response Note over C,K: 200: {authorization_code} C->>K: Access Token Request Note over C,K: {client_id, client_secret, auth_flow: "sdjwt-flow", auth_session, sdjwt_token} K-->>C: Access Token Response Note over C,K: 200: {access_token}Comments:
We could implement a functional PoC on this logic and are particularly seeking input from the community with the expectation to amend and contribute our code to Keycloak, enabling user authentication by presentation of an SD-JWT identity credential.
Useful links
All reactions