Certificate Bound Access Tokens about omejdn-server HOT 4 OPEN

This is related to the JWT bearer client authentication. Currently, the clients have certificates configured which are used as public keys for verification of the JWT assertion in the authentication.

Theoretically, we could use the information from those certificates dynamically and include them in the tokens instead of having it statically configured in addition to the public key x509 certificate.

RFC8705 seems to be overkill as we really do not want to implement TLS client authentication. However, using the confirmation claim seems doable as it does not seem to be restricted to the client authentication method as far as I can see.

I don't see how DPoP can be used without opening a whole lot of other issues related to certificate trust validation.

from omejdn-server.

My suggestion:

1. Strictly only use X.509 PEMs for the configured clients
2. Always put the X.509 thumbprints in the "cnf" claim as defined in https://www.iana.org/assignments/oauth-parameters/oauth-parameters.xhtml and RFC8705/7800

The transportCertsSha256 is out of scope for omejdn itself. The IDS-G may at some point support cnf claims. Until then, the claim needs to be configured manually.

from omejdn-server.

For those waiting for this issue to be addressed: This is a future enhancement and can automate how clients TLC certs can be mapped to the DAT. We currently also have the possibility to allow clients to overwrite claims via the request token so they can bind their identity to their TLS certificates.
@milux Can you provide details?

from omejdn-server.

@gbrost I can: https://www.ietf.org/archive/id/draft-spencer-oauth-claims-01.txt is mostly implemented in Omejdn as a straightforward extension of OIDCC functionality. To dynamically include attributes in an Access Token (=DAT in the IDS context), one needs to:

• Enable the Attribute Claim Mapper Plugin (Necessary for the DAPS anyway, done in omejdn-daps)
• Allow the attribute to have dynamically requested values in clients.yml:

  - key: transportCertsSha256
    value: "default value here"
    dynamic: true

• request values for the access_token sink according to the draft. Note that a) the claims parameter is not part of the client authentication token ("the request JWT") but a separate parameter (You should be using TLS, so that is not a security issue), and b) Omejdn in its default configuration always picks the first item in a values member. That part is up to the server though, so using the value member instead is recommended.

It may be best to collect any issues targeting the DAPS in particular here.

As for the method described in this issue: The main benefits to be had here are

• Less setup for new clients at Omejdn
• An implicit Proof of Posession for a client certificate related key by the client.

(Neither of which are of immediate benefit to the IDS ecosystem as far as I am aware)

I agree with @gbrost and @schanzen that this is a future enhancement which would probably require that either Omejdn comes with its own TLS implementation (unlikely) or special configuration of the reverse proxy to communicate the Client TLS certificate to Omejdn, where it can be added to an access token by a claim_mapper plugin.

from omejdn-server.