Dear Jaimandeep,
Regarding the first question.
If the token endpoint of an authorization server and protected resource
endpoints of a resource server directly communicate with client
applications, meaning that there is no reverse proxy in between the
endpoints and client applications, the endpoints must be able to extract a
client certificate directly from a mutual TLS connection.
On the other hand, if a reverse proxy sits in between the endpoints and
client applications, the reverse proxy must be able to extract a client
certificate from a mutual TLS connection and pass it to the endpoints
behind the reverse proxy. In turn, the endpoints must be able to receive a
client certificate from the reverse proxy. How a reverse proxy passes a
client certificate to the backend server depends on implementations.
In both patterns, details vary depending on implementations of web
frameworks and reverse proxies / API gateways. In the first pattern, for
example, in Java's Servlet API, endpoints can extract a client certificate
by calling
HttpServletRequest.getAttribute("javax.servlet.request.X509Certificate").
In the second pattern, X-Ssl-Cert and X-Ssl-Cert-Chain-* HTTP headers are
often used to convey a client certificate chain from a reverse proxy to a
backend server, but the HTTP headers are not standardized ones. There
exists a proposed standard that defines Client-Cert and Client-Cert-Chain
HTTP headers for the purpose (
https://datatracker.ietf.org/doc/draft-ietf-httpbis-client-cert-field/ ).
Cloud-based API gateway solutions often take their own approaches. For
example, in Amazon API Gateway, a Lambda function can extract a client
certificate from
event['requestContext']['authentication']['clientCert']['clientCertPem'] (
https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-lambda-authorizer-input.html
).
As listed above, there are a variety of ways to extract a client
certificate from a mutual TLS connection and pass it to endpoints. So, it
might not be appropriate to list implementation-specific examples in the
specification.
If you are interested in real examples, please read an online document
below where you can find "NGINX" and "Amazon API Gateway" examples.
Financial-grade Amazon API Gateway
https://www.authlete.com/developers/tutorial/financial_grade_apigateway/
Regarding the second question.
A resource server does not have to publish its public keys via "jwks_uri",
"jwks" or something equivalent unless the resource server wants the
authorization server to encrypt access tokens with an "asymmetric"
algorithm (where the resource server must hold a "private" key to decrypt
access tokens and the authorization server uses the corresponding "public"
key to encrypt access tokens).
PKI has already established a solid method to validate a certificate chain,
so there is little need to publish public keys for verifying certificate
signatures via "jwks_uri" or "jwks".
Best Regards,
Takahiko Kawasaki
On Tue, Aug 16, 2022 at 3:57 PM Jaimandeep Singh <jaimandeep.phdcs21=
40nfsu.ac...@dmarc.ietf.org> wrote:
> Hi All,
>
> 1. RFC 8705, requires thumbprint confirmation of the client certificate.
> It is the same client certificate which is used by client application while
> establishing mutual-TLS with the authorisation server or the protected
> resource server. I have not found any specific methodology in the RFC to
> get this client certificate from the mTLS stack to the OAuth stack for
> enabling thumbprint confirmation. Section 3.2 of RFC 8705 states:
>
> The protected resource compares that certificate hash to a hash of the
> client certificate used for mutual-TLS authentication and rejects the
> request if they do not match.
>
>
>
> 2. The RFC 8705 has provision of associating client certificate metadata
> in the form of 'jwks_uri' or 'jwks' with the authorisation server. Section
> 2.2.2. states
>
>> For the Self-Signed Certificate method of binding a certificate with a
>> client using mutual-TLS client authentication, the existing jwks_uri or
>> jwks metadata parameters from [RFC7591] are used to convey the client's
>> certificates via JSON Web Key (JWK) in a JWK Set [RFC7517].
>
> However, the RFC does not spell out any association of 'jwks_uri' or
> 'jwks' with protected resource servers. Also, as per RFC 7517 'jwks_uri'
> or 'jwks' is used at application level mostly to validate the signatures of
> the signed tokens. Is there any update in RFC for TLS to use 'jwks_uri' or
> 'jwks' as keystores for the client certificates in TLS based authentication
> mechanism? Section 2 of RFC 7517 states:
>
>> For instance, these keys might be used by some applications for
>> validating signed requests made to the token endpoint when using JWTs for
>> client authentication
>
>
> 3. It will be great if someone can help with clarity on the above aspects.
>
> Regards and Best Wishes
> Jaimandeep Singh
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
