Support for OAuth 2.0 Attestation-Based Client Authentication #40413

thomasdarimont · 2025-06-11T12:06:04Z

thomasdarimont
Jun 11, 2025
Collaborator

The OAuth 2.0 Attestation-Based Client Authentication defines an extension to the OAuth 2 which enables a Client Instance to include a key-bound attestation in interactions with an Authorization Server or a Resource Server. This new method enables Client Instances involved in a client deployment that is traditionally viewed as a public client, to be able to utilize this key-bound attestation to authenticate.

Having support for this in Keycloak would benefit use-cases involving Walltet attestation the upcoming OpenID4VCI standard,
see:

OpenID4VC High Assurance Interoperability Profile - Editor's draft
4.3.1. Wallet Attestation
OpenID for Verifiable Credential Issuance - draft 15 Appendix E. Wallet Attestations in JWT format
OAuth 2.0 Attestation-Based Client Authentication Draft 06

embesozzi · 2025-06-11T12:52:12Z

embesozzi
Jun 11, 2025

It's also useful in the OAuth 2.0 First-Party Apps context.

0 replies

babisRoutis · 2025-06-12T06:20:45Z

babisRoutis
Jun 12, 2025

Dear @thomasdarimont

That would be really awesome.

May I add a use case that could become major: Specification of Wallet Unit Attestations (WUA) used in issuance of PID and Attestations

To this text the term Wallet App Attestation refers to Wallet Attestation JWT from OpenId4VCI and/or Client Attestation JWT

I hope that if this feature is implemented it would be independent of KC's VC profile (I don't remember the exact name)

0 replies

babisRoutis · 2025-09-29T13:08:53Z

babisRoutis
Sep 29, 2025

The published OpenId4VCI v1 explicitly requires use of draft 7 of Attestation-based client authentication.

To this draft 7, there is a notable change related to the introduction of the challenge_endpoint to the AS, that if specified must be used by the client/wallet to obtain a fresh challenge used in the Client Attestation PoP JWT.

Some thoughts with regards to a potential implementation

The new authentication method can be independent of the VCI feature.
Trust between the KC and the Client Attester( aka Wallet Providers) that issues and signs Client Attestation JWT should be abstracted. A JWKSet or a keystore can be a sensible default solution, yet there would be cases that client attester pub keys could be specified with alternative means (for instance Trusted Lists)
The challenge_endpoint could re-use the nonce_endpoint code/approach, as implemented by the VCI feature,

0 replies

VinodAnandan · 2025-10-01T10:52:41Z

VinodAnandan
Oct 1, 2025

@thomasdarimont @babisRoutis Could we please create a GitHub issue for this?

1 reply

babisRoutis Oct 1, 2025

@thomasdarimont @babisRoutis Could we please create a GitHub issue for this?

Hi

Created #43136

mposolda · 2026-04-09T15:59:58Z

mposolda
Apr 9, 2026
Maintainer

One of the questions regarding the implementation of ABCA is how to provision the keys, which Keycloak should trust for verifying the client attestation JWT.

The related feature client-auth-federated (supported since Keycloak 26.6.0) uses identity providers as a way for Keycloak to provision public keys, which should be trusted. For example for the OIDCIdentityProvider, the key can be downloaded from configured JWKS URL or hardcoded. There are also some other impls like "Spiffe" or "Kubernetes" identity providers. More on this in Keycloak docs (See the section Signed JWT issued by an Identity Provider in that chapter).

Can the attestation based client authentication also use identity providers in similar way like client-auth-federated ? Would it work with OID4VCI HAIP testsuite?

1 reply

tdiesler Apr 10, 2026

Can the attestation based client authentication also use identity providers in similar way like client-auth-federated ? Would it work with OID4VCI HAIP testsuite?

Yes, that should work. Currently, it works such that an RSA-P256 key-pair with X5C Certificate is externally generated and then added to the these suite configuration, like this ...

        "client_attester_keys_jwks": {
            "keys": [
                {
                    "kty": "RSA",
                    "kid": "openid-abca-attester-key",
                    "use": "sig",
                    "alg": "PS256",
                    "n": "q1Lixv3MJtq8HfIiiINrqnx4co2In0keBxJDWfO0ssmu6w7SOO5y4eeI-y8_y6XXYD_k-TtD24RsnmCW1xdQ5gRpcGBrvBG3A35Qm6el1jLab3Bu23vicykji8vX1L-ICMpFH142erKJuy8Ko4mYbZTZiiYQBOcCIYtskuHHtoel0SIyDzhENyU69N3RYYGtnuGgf7pTJGHty0OQDpUaLhFyTJZ4voWq_X1QeM617VLRcSt9IyBTxYq7tNVurIdyAdEKMGHL8Fpur7mF-paPqj7KBtvTawHOQDOlEG253kT8AK-QqtWPw0grAI8TJYsVhsf88gn6h4ss5pC7aMGQmw",
                    "e": "AQAB",
                    "d": "QnX_emF3YnVFN7q4UcvlpvftQ8cLAnu7VdPsY8dKSHc7z3zq6WH7GA6ZUZP1RBucLv7qZRLsEorPFitzKJKnc-uvOYR2FrmqjQTh4VhKWYtVuJhdsPBgmvsRCoizvBjm_T32TaJfMP70tjQcBO_6PTxanaCBY114MqojHuHOd0yJm4QXum0p5lgAdKbhzNOo-E6CSI5ym5lVo0GgakXOz0Kc69i7MoIEgWP-vkVS5CBAOtwLLaIW_jAxXhZwcfNuH-BduunZIsdv5eZRO_f8k9zGB96h4IhcUmEro-aXdQRIzfjSYJIjVBSEarMSQOcMp4osOYhQ1XguSlIn5YrjwQ",
                    "p": "vPv5F9R1ndBi8WRIfISHSzdA_d3lCBLnnrnR47H7r682iW5cREGNe7VpEY640CYgAK6xDW8ZwPPKmjBM0QUXudZ8D0xAq2nhTN6Z6UuNud996QPBr9C9v9mu5yDoymXaQChRL8feOiE473NERWp-sQiY2o6TMgra5wNmPppdGts",
                    "q": "6BOwjcvOc_-zCguZG6bTOfiq7OIozBzNKajI6b2r23lJmdqM7Ma--Ff9IADtZtk3X5K9zOdusz12Fbk9LOXSoW84WLhhytp02xiPEGntA0mE11GgelGeGoGrubsdnAYi-IVdeUabpLIqxw57p-pKhTPZLI0yQcz08upQ2EUT7UE",
                    "dp": "ECPA0T0u0kyCtrTmz-ONnmnYnhW-QqNCrraV60k_AnEHSlNng9jJWYBTudEjjXtEDmrc6hXL8EOh0OtBFDTIIvHjZHcRqtH_EM6N_HOcZfxlR2ovt3EvU1wm6MxRtT9flU0cKeV64CIIN8LzWK5QpZPjYf79KS_uI_6RU9VhEDM",
                    "dq": "pafIUq6zw2E1r2nv9Cj0hWDWwRf9_xRf7eio4Q-eaJ7-xm-WQDzte99yszF2Q_-w4uufx287OX4ZmBANdsrluo3lLo8OXvnoh6vUEudJYxtLU1bUsfsoW8tLhNvnmsNWmwa3XiXkW39Bway433cBkmscDg0LXqSqA-r1oipMuwE",
                    "qi": "Ae_t1NeK5FWZKwcDVBWckbZlcXKK45pLmuVo21K79SHi3PykZbS4WA0Pv8Rtmg7OLZj-QKoQcRlI4WYgoY9hUez-V1oe1w2KD44e3IRwxVYvfCrHx1I7VHYP-TKmE-jXOIdtvLHLKB9QtRI1fztyaTQ3_gZZ_Az78eYKobpKUCs",
                    "x5c": [
                        "MIIDIjCCAdagAwIBAgIGAZ1xd6DUMEEGCSqGSIb3DQEBCjA0oA8wDQYJYIZIAWUDBAIBBQChHDAaBgkqhkiG9w0BAQgwDQYJYIZIAWUDBAIBBQCiAwIBIDAeMRwwGgYDVQQDDBNnaXRodWIuY29tL2tleWNsb2FrMB4XDTI2MDQwOTA4NTkxOFoXDTM2MDQwNjA4NTkxOFowHjEcMBoGA1UEAwwTZ2l0aHViLmNvbS9rZXljbG9hazCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKtS4sb9zCbavB3yIoiDa6p8eHKNiJ9JHgcSQ1nztLLJrusO0jjucuHniPsvP8ul12A/5Pk7Q9uEbJ5gltcXUOYEaXBga7wRtwN+UJunpdYy2m9wbtt74nMpI4vL19S/iAjKRR9eNnqyibsvCqOJmG2U2YomEATnAiGLbJLhx7aHpdEiMg84RDclOvTd0WGBrZ7hoH+6UyRh7ctDkA6VGi4RckyWeL6Fqv19UHjOte1S0XErfSMgU8WKu7TVbqyHcgHRCjBhy/Babq+5hfqWj6o+ygbb02sBzkAzpRBtud5E/ACvkKrVj8NIKwCPEyWLFYbH/PIJ+oeLLOaQu2jBkJsCAwEAATBBBgkqhkiG9w0BAQowNKAPMA0GCWCGSAFlAwQCAQUAoRwwGgYJKoZIhvcNAQEIMA0GCWCGSAFlAwQCAQUAogMCASADggEBAImAY92qFQeLpL9n6S7HHpLxLNoE6LE+5mpUUJM/tc2+TJ8xx2cpdzHohTAozwTuAYgmH5XlTH79ra2UlXrtNVvSKl5Ae+aByRCqRs/sKdwl5gdGW6eMwlLdkg4peKuGIG2j5ud7Pg29LrbRA88cIpzIcKr6JumS13eQ3AQKsB6xjxgv0KmQrDd7kBUb7hmedLYWLn/SEmpLiftIPOQM8oWJF0erFT5otZ0KlmTLstyM1yoEX6RpYc3rP0cbcCDA20PQQAX/fO/1MS7+Q23Rg7goSSsL0gZPSjiPcowd/dcFqsFkZ/KElrM1MJjccLJF/egUE4VjtLvrHMRe3tGtX/s="
                    ]
                }
            ]
        },

We then reduce that to public keys (just one for now) and add it to the AttestationBasedClientAuthenticator config.

i.e. currently it can be done via Admin UI and kcadm like scripted here

VinodAnandan · 2026-04-10T08:36:18Z

VinodAnandan
Apr 10, 2026

I completely agree with Marek here! It definitely looks similar since we're outsourcing/federating the client auth trust to an external entity.

Quick question on that note: I was looking over the 'eyJ0eXAiOiJvYXV0aC1jbGllbnQtYXR0ZXN0YXRpb24 rand0IiwiYWxnIjoiRVMyNTYiLCJraWQiOiIxMSJ9.eyJzdWIiOiJodHRwczovL2NsaWV udC5leGFtcGxlLmNvbSIsImlhdCI6MTc3MjQ4NzU5NSwiZXhwIjoyNTI5ODY2Mzk0LCJj bmYiOnsiandrIjp7Imt0eSI6IkVDIiwidXNlIjoic2lnIiwiY3J2IjoiUC0yNTYiLCJ4I joiVmNLVk5CWjRJYUJBWVczanhNNHczVEpGVkE3bXllVUdReUd0LWdfeXZwUSIsInkiOi JmLUUtaFlFM1RBV0t3aFZ2OXBlajlOQUJzOVNYOVhzTk84MHg1N2pGVHlVIn19fQ._TS4 d-LAnRlwdN97wiVnl4z7C9gvm45IWr-BvGTzeZaHtZtgNZ88gvzroU3LElUPbgF4kWi_D FORnKzsx5yu6A' and noticed there's no 'issuer' in the OAuth-Client-Attestation JWT. I'm a bit curious about how we should handle the trust anchoring process, will we need to point to a JWKS endpoint or public keys, etc.?

@babisRoutis @mposolda @thomasdarimont @embesozzi @tdiesler I'd really love and appreciate any thoughts or ideas you all might have on this!

9 replies

tdiesler Apr 13, 2026

I think we need to get started somewhere - currently there is the ootb mechanism of providing the AttestationBasedClientAuthenticator with a config that atm contains known attester keys. This mechanism can of course be swapped out for something else. I noticed for example that there is a similar need for known public keys with key 'attestation' proofs - it uses a three layer lookup mechanism that can read the known keys from realm attributes. This could be one candidate for a unified key discovery mechanism.

However, first we need the initial implementation in place so that it can provide the stage for qualified feedback i.e. folks must be able to try it in order to comment on it

tbloomfi May 15, 2026

In some pilot work I am involved in, the jwks_uri is used. Clients (wallet service) need to authenticate and register the URI to the AS (or have the URI registered). We also support registering specific keys but this will be very messy when keys are rotated. The DevOps team was not happy with registering specific keys.

This approach assumes a small trusted set of wallets. At a certain level of scale a registry would be required which is a future consideration for our specific use case.

The issuer (resource server) is also notified of the wallet details. They can still choose to reject a specific trusted wallet.

tdiesler May 18, 2026

Conceptually, there are three keys involved

The ABCA client key is known to the Attester and trusted by the AS because the Attester trusts it. This could be a key representing a particular wallet vendor+version.
The Wallet may use DPoP for protocol layer security - message replay and such. It establishes trust for the messages in the the conversation
The Holder 8000 Key (also maintained by the wallet) binds the credential to the Holder - it shows up in the proofs associated with the credential request

The first and second may be the same (not recommended) the Holder key will not be something the Attester needs to know.

babisRoutis May 18, 2026

The first and second may be the same (not recommended) the Holder key will not be something the Attester needs to know.

Good morning @tdiesler

Currently, the Client Instance Key found to the Client Attestation JWT (cnf.jwk claim) and the DPoP key are not related.

In the context of EUDIW, there would be a requirement that the Client Instance Key will be used to sign both the Client Attestation PoP JWT AND the DPoP.
For reference check here, in particular the changes made in v1.5.1.

Finally, it seems that ABCA specification is moving towards optimizing the PoP of a client attestation, defining two options:

Client Attestation JWT + Client Attestation PoP JWT (current) and
Client Attestation JWT + DPoP JWT (new feature), where DPoP is signed by the Client Instance Key.
For reference check here

tdiesler May 18, 2026

We are currently bound by the OpenID FAPI2 and HAIP profiles. Some of the newer developments and spec updates are not (yet) covered by the conformance test suite, I can therefore only answer to what is covered by those profiles.

Support for OAuth 2.0 Attestation-Based Client Authentication #40413

Uh oh!

Uh oh!

thomasdarimont Jun 11, 2025 Collaborator

Replies: 6 comments · 11 replies

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

mposolda Apr 9, 2026 Maintainer

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

thomasdarimont
Jun 11, 2025
Collaborator

Replies: 6 comments 11 replies

mposolda
Apr 9, 2026
Maintainer