Subject: [OAUTH-WG] Purpose of client authentication for "public" client types

From: STAS Thibault <[email-masked]>
Date: Wed, 25 Aug 2021 13:59:44 +0000

Dear,

I notice that many API Gateway providers are requiring the authentication of
the client, even for public client types.

e.g.

https://docs.apigee.com/api-platform/security/oauth/implementing-password-gr
ant-type

https://auth0.com/docs/flows/call-your-api-using-resource-owner-password-flo
w

https://tyk.io/docs/basic-config-and-security/security/authentication-author
ization/oauth2-0/username-password-grant/

Not many providers are make the use of the client authentication optional,
as the client_secret is always present in either the Authorization Basic
header or within the payload.

What is the added value to perform client application authentication in the
context of "public" client type, like a vendor application sold to many
customers.?

The client_secret would be shipped along with the application, putting at
risk the secrecy of the client_secret.

The oAuth standard does not seem to provide a lot of guidance with regards
to the use and need of the client authentication in such context.

Would it not be preferable to recommend client identification rather than
client authentication in combination with resource-owner authentication ?

The client_id could be provided as part of the selected grant type
parameters.

 

Kind regards,

Thibault STAS 

SWIFT | Enterprise Architect - Information Technology

Tel: + 32 2 655 4975

 <http://www.swift.com> www.swift.com

This e-mail and any attachments thereto may contain information which is
confidential and/or proprietary and intended for the sole use of the
recipient(s) named above. If you have received this e-mail in error, please
immediately notify the sender and delete the mail.  Thank you for your
co-operation.  SWIFT reserves the right to retain e-mail messages on its
systems and, under circumstances permitted by applicable law, to monitor and
intercept e-mail messages to and from its systems.

---

From: George Fletcher <[email-masked]>
Date: Fri, 27 Aug 2021 15:00:13 -0400

While not widely deployed, the OAuth2 solution to a deployment of 
"public clients" that need to be able to transition to "confidential 
clients" so that client authentication makes sense, is to use Dynamic 
Client Registration (RFC 7591).

Dynamic Client Registration allows the public client to register and 
obtain (or provide) a client secret that is unique to that instance of 
the app. At that point, the client can authenticate to the backend 
services as needed. This model increases the security of the solution 
and decreases the risk while also providing a stepping stone to moving 
away from Bearer tokens to proof-of-possession model for tokens.

General best practice is to have the public client create a 
public/private key pair and register the public key as part of the 
registration event. The client can then prove its authenticity by 
signing data with the private key and the backend can validate via the 
public key. In the case of many mobile platforms, the public/private key 
pair can be created in the secure enclave of the device adding 
additional security protection for the private key.

As for risk with the deployment mechanisms used by the API Gateways, 
there is really no additional risk and no additional security benefit 
for providing the secret in the public client. Both clients can be 
easily impersonated so the gateway MUST treat a client secret coming 
from a public client with the exact same risk measurement as a request 
coming from a public client without the client secret. Basically, the 
risk/security is the same. There may, however, be backend developer 
benefit by keeping the flows more similar.

Thanks,
George

On 8/25/21 9:59 AM, STAS Thibault wrote:
>
> Dear,
>
> I notice that many API Gateway providers are requiring the 
> authentication of the client, even for public client types.
>
> e.g.
>
> https://docs.apigee.com/api-platform/security/oauth/implementing-password-grant-type 
> <https://docs.apigee.com/api-platform/security/oauth/implementing-password-grant-type>
>
> https://auth0.com/docs/flows/call-your-api-using-resource-owner-password-flow 
> <https://auth0.com/docs/flows/call-your-api-using-resource-owner-password-flow>
>
> https://tyk.io/docs/basic-config-and-security/security/authentication-authorization/oauth2-0/username-password-grant/ 
> <https://tyk.io/docs/basic-config-and-security/security/authentication-authorization/oauth2-0/username-password-grant/>
>
> Not many providers are make the use of the client authentication 
> optional, as the client_secret is always present in either the 
> Authorization Basic header or within the payload.
>
> What is the added value to perform client application authentication 
> in the context of �public� client type, like a vendor application sold 
> to many customers�?
>
> The client_secret would be shipped along with the application, putting 
> at risk the secrecy of the client_secret.
>
> The oAuth standard does not seem to provide a lot of guidance with 
> regards to the use and need of the client authentication in such context.
>
> Would it not be preferable to recommend client identification rather 
> than client authentication in combination with resource-owner 
> authentication ?
>
> **
> *Thibault STAS *
> SWIFT | Enterprise Architect � Information Technology
>
> Tel: + 32 2 655 4975
>
>
> www.swift.com <http://www.swift.com>
>
> This e-mail and any attachments thereto may contain information which 
> is confidential and/or proprietary and�intended for the sole use of 
> the recipient(s) named above. If you have received this e-mail in 
> error, please immediately notify the sender and delete the mail.� 
> Thank you for your co-operation.� SWIFT reserves the right to retain 
> e-mail messages on its systems and, under circumstances permitted by 
> applicable law, to monitor and intercept e-mail messages to and from 
> its systems.
>
>
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth