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 ?
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 <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 protected]
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
