OIDC MTLS Binding support

[Sergey Beryozkin]

Hi Everyone,

Going forward we are going to update the dev community on some of the most significant Quarkus security related updates that can be of interest, for the community to provide the feedback, extra reviews, and be aware of the upcoming, possibly migration-level changes.

So I'll start with talking about a new enhancement being underway which is OpenId Connect (OIDC) Mutual TLS Binding for OIDC Bearer access tokens.

What is it about ? It is possibly the strongest measure possible against the access token theft.

For example, when someone sends a Bearer access token over HTTP ("Authorization: Bearer token"), it is impossible, without this feature, to assert that the client which sends the token is the one this token was issued to.

The technical details can be found for example here:

https://www.rfc-editor.org/rfc/rfc8705#name-mutual-tls-client-certifica

and it works like this  OIDC client uses MTLS to acquire a token from the OIDC provider token endpoint and uses MTLS to access Quarkus using the same certificate - Quarkus will introspect the access token and will be able to assert that this token is bound to the current client certificate.

As far as Quarkus is concerned it can be achieved in 2 steps:

- Enhance Quarkus Security to support `inclusive` authentication, meaning that all registered authentication mechanisms must create corresponding security identities. For example, if both MTLS and OIDC mechanisms are enabled, both mechanisms must successfully create SecurityIdentity - right now the authentication flow is finalized as soon as the first SecurityIdenteiy is created, PR in progress is here:

https://github.com/quarkusio/quarkus/pull/31329

- And then, it is just making sure, at the OIDC level that the access token can be linked to the current certificate (get the certificate thumbprint etc from the token claim or introspection and check against the certificate)

This OIDC/OAuth2 MTLS binding feature has been introduced because using the bearer access tokens in some sensitive environments such as financial institutions is not an option. It gives a `Holder Of` support for the access tokens.

Cheers, Sergey

[Sergey Beryozkin]

This is back on track with Michal reviving the inclusive authentication work

On Mon, Mar 20, 2023 at 6:33 PM Sergey Beryozkin <sbia...@redhat.com> wrote:

Hi Everyone,

Going forward we are going to update the dev community on some of the most significant Quarkus security related updates that can be of interest, for the community to provide the feedback, extra reviews, and be aware of the upcoming, possibly migration-level changes.

So I'll start with talking about a new enhancement being underway which is OpenId Connect (OIDC) Mutual TLS Binding for OIDC Bearer access tokens.

What is it about ? It is possibly the strongest measure possible against the access token theft.

For example, when someone sends a Bearer access token over HTTP ("Authorization: Bearer token"), it is impossible, without this feature, to assert that the client which sends the token is the one this token was issued to.

The technical details can be found for example here:

https://www.rfc-editor.org/rfc/rfc8705#name-mutual-tls-client-certifica

and it works like this  OIDC client uses MTLS to acquire a token from the OIDC provider token endpoint and uses MTLS to access Quarkus using the same certificate - Quarkus will introspect the access token and will be able to assert that this token is bound to the current client certificate.

As far as Quarkus is concerned it can be achieved in 2 steps:

- Enhance Quarkus Security to support `inclusive` authentication, meaning that all registered authentication mechanisms must create corresponding security identities. For example, if both MTLS and OIDC mechanisms are enabled, both mechanisms must successfully create SecurityIdentity - right now the authentication flow is finalized as soon as the first SecurityIdenteiy is created, PR in progress is here:

https://github.com/quarkusio/quarkus/pull/31329

Newer and better PR from Michal is here:

https://github.com/quarkusio/quarkus/pull/42935

 

- And then, it is just making sure, at the OIDC level that the access token can be linked to the current certificate (get the certificate thumbprint etc from the token claim or introspection and check against the certificate)

This OIDC/OAuth2 MTLS binding feature has been introduced because using the bearer access tokens in some sensitive environments such as financial institutions is not an option. It gives a `Holder Of` support for the access tokens.

While OIDC MTLS token binding feature will benefit, an inclusive authentication feature will be of help in different scenarios, I have seen several related user queries.

Enforcing more than one authentication mechanism endorsement at the same time with a single extra property will help users support stricter authentication controls

Thanks, Sergey

 

Cheers, Sergey