MTLS client authentication and certificate bound access tokens about fosite

[james-d-elliott]

I have a little bit of information about this, though fairly unhelpful as it was basically already mentioned. It seems that other providers provide instructions for the proxy admin on how it is to be configured. For example this is KeyCloak's instructions.

The interface is easily the best option as already mentioned as it's provider agnostic. Reasonably it could be accompanied with an implementation which just requires the appropriate header names which assumes the contents are using the url-encoded PEM which should suffice for most cases.

[vivshankar]

@aeneasr I have an implementation for this that I can contribute. Please let me know if there's interest.

[mitar]

I think until RFC becomes a standard and not just proposed standard, this will not be accepted.

[vivshankar]

It isn't draft. It's been the only full RFC for sender constrained access tokens. You might be thinking about DPoP.

@mitar

[mitar]

Oh, sorry. I misread. Ignore my comment.

[aeneasr]

If we implement tls_client_auth I think it would be straight forward to also add self_signed_tls_client_auth. Or is there a reason why that would be a non-goal?

Regarding the mTLS handshake, would that not be trivial to implement using Go's HTTPS infrastructure? Or are there specifics required to deal with mTLS?

[vivshankar]

@aeneasr self_signed_tls_client_auth can be done but I don't see a lot of value with that implementation. tls_client_auth is used extensively particularly for Financial API regulated implementations.

With regards to the mTLS handshake, the infrastructure is unlikely to use the OAuth provider as the edge. SSL handshakes would be typically intercepted at an edge service like F5, Akamai, Cloudflare etc and the typical architecture I have seen is where they perform the mutual trust handshake and send down the client certificate as a header to the OAuth provider.

Also, this is Fosite and not Hydra. Certainly the web interface to enforce mTLS can be added to Hydra.

[aeneasr]

I see, that makes a lot of sense. Is the header where the certificate is included somehow standardized across these providers?

Regarding self_signed_tls_client_auth, I think it makes sense for third-party OAuth2 clients that wish to use mTLS but do not have the ability to either (a) purchase a certificate from e.g DigiCert or (b) do not have the ability to register a CA with the provider. It would also support use cases that want to leverage mTLS without needing to implement a full PKI infrastructure - this would be similar to the JWT client authentication but using mTLS instead. We could make this optional though, of course, if you are working in a regulated environment that mandates a well-known CA to have issued the certs. WDYT?

[vivshankar]

@aeneasr You really need to learn how to take vacation 😁

The header approach is very common. Akamai, for example, offers the ability to include the full PEM and/or parsed PEM attributes. Most proxies offer this, nginx included. I suggest if Oathkeeper (the ory proxy? Cool names BTW) doesn't, you might consider enhancing it to make this available for people who want to use a pure ory solution with DNS resolution leading direct to Oathkeeper. In my own implementation, we use Akamai as the SSL termination point and it does the job of sending down the PEM post-mTLS handshake.

I can see the value of self_signed_tls_client_auth for test environments but I don't see this adding a lot of value once DPoP becomes a RFC implementation. In any case, we can pull it into the scope. I just don't have a ready implementation for this. Anyway, it just needs an additional jwks validation. Does it make sense, in this case, to configure the TLSAuthenticatedClient with another property that indicates the kid in the jwks? This would avoid needing to loop the entire jwks looking for a match.

Edit: Your question regarding a standard cert header name... there isn't one, which is why I am proposing this as a new property we add to compose.Config (ClientCertificateHeaderName or some such).

[aeneasr]

Edit: Your question regarding a standard cert header name... there isn't one, which is why I am proposing this as a new property we add to compose.Config (ClientCertificateHeaderName or some such).

I see, that makes sense to me! Is the format at least standardized?

I can see the value of self_signed_tls_client_auth for test environments but I don't see this adding a lot of value once DPoP becomes a RFC implementation.

That makes sense to me, I think it will be useful for guides and examples that allow one to get off the ground quickly!

I suggest if Oathkeeper (the ory proxy? Cool names BTW) doesn't, you might consider enhancing it to make this available for people who want to use a pure ory solution with DNS resolution leading direct to Oathkeeper.

That's a good proposal, we'll include it in the scope of the Ory Oathkeeper refactoring :)

@aeneasr You really need to learn how to take vacation

I know 😅

[vivshankar]

The certificate format is usually url-encoded pem but the proxy may also have the ability to send certificate attributes and computed values. Here's a snippet from Cloudflare:

For companies that use the client certificate for identification, Cloudflare can also forward any field of the client certificate as a custom header.

I know Akamai can be configured to send the pem cert.

[aeneasr]

I see, in that case it probably makes sense to have an interface defined which can be implemented for different providers (Akamai, Cloudflare, ...) as it sounds like everyone is doing this a little differently? That way, we could probably do away with the custom header config and just rely on the provider? We can also implement a generic provider which is a bit configurable to cover common use cases?

[vivshankar]

OK that makes sense. Maybe a tailored session interface that provides functions to get pem or specific attributes or the computed fingerprint?

[aeneasr]

makes sense!

[github-actions]

Hello contributors!

I am marking this issue as stale as it has not received any engagement from the community or maintainers for a year. That does not imply that the issue has no merit! If you feel strongly about this issue

• open a PR referencing and resolving the issue;
• leave a comment on it and discuss ideas on how you could contribute towards resolving it;
• leave a comment and describe in detail why this issue is critical for your use case;
• open a new issue with updated details and a plan for resolving the issue.

Throughout its lifetime, Ory has received over 10.000 issues and PRs. To sustain that growth, we need to prioritize and focus on issues that are important to the community. A good indication of importance, and thus priority, is activity on a topic.

Unfortunately, burnout has become a topic of concern amongst open-source projects.

It can lead to severe personal and health issues as well as opening catastrophic attack vectors.

The motivation for this automation is to help prioritize issues in the backlog and not ignore, reject, or belittle anyone.

If this issue was marked as stale erroneously you can exempt it by adding the backlog label, assigning someone, or setting a milestone for it.

Thank you for your understanding and to anyone who participated in the conversation! And as written above, please do participate in the conversation if this topic is important to you!

Thank you 🙏✌️

[vivshankar]

Yes, I need to get back to contributing here. Assuming this is still of interest, I will try to get this in place over the next couple weeks.