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.

 

Attachment: smime.p7s
Description: S/MIME cryptographic signature

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

Reply via email to