Subject: [OAUTH-WG] client authentication

From: Jaap Francke <[email-masked]>
Date: Tue, 17 Sep 2019 13:20:39 +0000

Hi all,

I was exploring the topic of client authentication in various RFCs.
A few things are not 100% clear to me, I would be interested to get your feedback.

RFC7591 sets up the registry for client authentication methods on the token endpoint and adds:
- none
- client_secret_basic (RFC2617)
- client_secret_post (RFC6749)

I don’t understand why that registry seems limited to the token-endpoint. Client authentication also applies to other protected (OAuth) endpoints such as token introspect, so it makes sense to have a generic (OAuth) client authentication method registry.

OIDC specs indicate a few more:
- client_secret_jwt
- private_key_jwt
Is my understanding correct that client_secret_jwt refers to the same client authentication method as described in https://tools.ietf.org/html/rfc7523#section-2.2 ?

Furthermore there is RFC6750 which suggest 3 client authentication mechanisms which are not included in the registry:
- Bearer / authorisation request header
- bearer / URI query parameter
- bearer / form encoded body parameter
For example, the RFC7662 suggests to use the “bearer / authorisation request header” mechanism as client authentication/authorisation mechanism.
Any reason why this was not done?

Thanks in advance for any related feedback, regards,

Jaap Francke

---

From: Filip Skokan <[email-masked]>
Date: Tue, 17 Sep 2019 15:52:41 +0200

Hello Jaap,

There are currently 7 registered
<https://www.iana.org/assignments/oauth-parameters/oauth-parameters.xhtml#token-endpoint-auth-method>
client authentication methods that are defined by various RFC's.

There are the three from RFC6749 which got their names registered in
RFC7591 - none, client_secret_basic and client_secret_post. (Please note
that RFC2617 IS NOT EQUAL to client_secret_basic - there are additional
requirements when it comes to encoding the username:password tokens defined
RFC 6749 Appendix B)

Then the two _jwt ones from RFC7523 that got their names registered as part
of OIDC Core 1.0 (yes, they're the same).

The two remaining are from draft-ietf-oauth-mtls and use mutual-TLS client
certificates for authentication.

RFC6750 does not define client authentication method. It defines different
means of using a Bearer Token obtained through any of the available flows
to access a protected resource.

Ad RFC7662) its at the discretion of the AS to require either a Bearer
Token or Client Authentication to access the introspection response, it may
or may not support both in which case the claims it returns may be limited
and also the means of obtaining that Bearer Token is out of scope of the
document.

Hope this helps,

Best,
*Filip*

On Tue, 17 Sep 2019 at 15:21, Jaap Francke <[email-masked]>
wrote:

> I don’t understand why that registry seems limited to the token-endpoint.
> Client authentication also applies to other protected (OAuth) endpoints
> such as token introspect, so it makes sense to have a generic (OAuth)
> client authentication method registry.
>
> Is my understanding correct that client_secret_jwt refers to the same
> client authentication method as described in
> https://tools.ietf.org/html/rfc7523#section-2.2 ?
>
> Furthermore there is RFC6750 which suggest 3 client authentication
> mechanisms which are not included in the registry:
> For example, the RFC7662 suggests to use the “bearer / authorisation
> request header” mechanism as client authentication/authorisation mechanism.
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>