Certificate Bound Access Tokens

[bellebaum]

Omejdn is occasionally used in a way that allows to bind transport certificates to the issued access tokens. This can be quite useful if access tokens are not to be reused by resource servers and other parties receiving such tokens.

One example usage: IDS-G defines transportCertsSha256

As Omejdn does not support detecting transport certificates (nor requests them), this parameter is usually configured though the attributes of clients or users, and subsequently included in the issued access tokens. This is quite inflexible and requires updates either via the API or manually.

Alternatives:

• RFC 8705 provides a direct way to hint at the client's certificate used for TLS in the cnf.x5t#S256 claim of the access token. TLS Client authentication can also be made optional by providing specialized endpoints requiring it.
  • This is quite elegant but does require direct access to the TLS certificates. This may be done using NginX's features to convey them in a header, but this would possibly restrict the setups which may involve Omejdn.
  • We could also just do TLS inside Omejdn.
• DPoP sends a Proof of Posession as an HTTP Header.
  • Easier to work with for Omejdn, but does require clients to have access to their keys at an application layer.

[schanzen]

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.

[schanzen]

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.

[gbrost]

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?

[bellebaum]

@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.