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

[George Fletcher]

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://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/ 



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


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
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[STAS Thibault]

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


  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.

 



smime.p7s
Description: S/MIME cryptographic signature
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth