Hi Emelia, Regarding your comment: “'MAY use the 'client_id' request parameter to identify itself' isn't exactly clear whether that's query string or form post data, since 'request parameter' isn't explicitly defined there: https://www.rfc-editor.org/rfc/rfc6749#section-3.2”
In Section 3.2, there is a reference to Section 2.3 at the beginning: > Confidential clients or other clients issued client credentials MUST > authenticate with the authorization server as described in Section 2.3 when > making requests to the token endpoint. In Section 2.3, when discussing the “client_id,” it clearly states: > The parameters can only be transmitted in the request-body and MUST NOT be > included in the request URI. So, to me, it is clear that using `client_id` as a query parameter is not valid…. As for your other point: “It seems like it'd be good to actually have a formalized I-D/RFC that says 'this is exactly what these client authentication mechanisms are,' since the original RFC leaves a lot of things up to interpretation.” You are right, something that maybe can help is to read the new OAuth 2.1 (still in draft): https://datatracker.ietf.org/doc/html/draft-ietf-oauth-v2-1-12. This draft can help clarify some of the ambiguities in the original OAuth 2 specification. Best regards. From: emelia <emelia=40brandedcode....@dmarc.ietf.org> Date: Tuesday, 22 April 2025 at 20:45 To: Oliva Fernandez, Jorge <jorge.olivafernan...@santander.co.uk> Cc: OAuth WG <oauth@ietf.org> Subject: [EXT]Re: [OAUTH-WG] Question on Client Authentication mechanisms CAUTION: This message is from an EXTERNAL sender – be vigilant, particularly with links and attachments. If you suspect it, report it immediately using the phishing button. Hi Jorge, et al, Yeah, my understanding is that if you don't have a client_secret, then you cannot use `client_secret_basic` or `client_secret_post`, but you would have to use `none` and pass the `client_id` via form post data or maybe via query string — "MAY use the 'client_id' request parameter to identify itself" isn't exactly clear whether that's query string or form post data, since "request parameter" isn't explicitly defined there: https://www.rfc-editor.org/rfc/rfc6749#section-3.2 It seems like it'd be good to actually have a formalised I-D/RFC that says "this is exactly what these client authentication mechanisms are", since the original RFC leaves a lot of things up to interpretation. I've currently gone with implementing `client_secret_basic` and `client_secret_post` as requiring a client_secret, which I think is logical, and if you don't have a secret, then you use `none` — Emelia On 22 Apr 2025, at 12:05, Oliva Fernandez, Jorge <Jorge.OlivaFernandez=40santander.co...@dmarc.ietf.org> wrote: Hi Emelia, Some time ago, I also came across this text: “The client MAY omit the parameter if the client secret is an empty string,” and I started racking my brain trying to understand it. The long answer can be found in an email thread from the list (13 years ago now) where it was mentioned that this text was introduced: https://mailarchive.ietf.org/arch/msg/oauth/tHy-Dmqjg1uUaW3tfPnkmO6_AA8/ If you take a look at the email thread, you’ll see that the discussion revolved around two main points: - When the `client_id` field is mandatory or not. For example, when Basic authentication is used, the `client_id` is duplicated in both the header and the body of the request. - The differences between authentication and identification across different endpoints. For the `/authorize` endpoint, the `client_id` serves the purpose of identification, whereas for the `/token` endpoint, the `client_id` was intended for authentication and therefore also requires some kind of password or `client_secret`. However, for use cases where a public client uses the `/token` endpoint, if the `client_id` is not mandatory, there’s no way to identify this OAuth client and associate tokens/refresh tokens with it. Additionally, you’ll notice in the thread that this text wasn’t added in isolation. The specific update addressed two points: ```txt Added to 2.4.1: client_secret REQUIRED. The client secret. The client MAY omit the parameter if the client secret is an empty string. Added to 3.2.1: A public client that was not issued a client password MAY use the 'client_id' request parameter to identify itself when sending requests to the token endpoint. ``` My understanding and interpretation of this are that there was a need to clarify that the `client_id` should be sent to the `/token` endpoint when using public clients, and that the `client_secret` is only required when the client has a secret (`client_secret_post`). In my experience with certified OAuth/OIDC libraries, if you specify `client_secret_basic` or `client_secret_post` as the token endpoint authentication method, the `client_secret` parameter becomes mandatory. This makes sense because it is marked as REQUIRED in Section 2.4.1. Best regards, From: emelia <emelia=40brandedcode....@dmarc.ietf.org<mailto:emelia=40brandedcode....@dmarc.ietf.org>> Date: Monday, 21 April 2025 at 17:06 To: OAuth WG <oauth@ietf.org<mailto:oauth@ietf.org>> Subject: [EXT][OAUTH-WG] Question on Client Authentication mechanisms CAUTION: This message is from an EXTERNAL sender – be vigilant, particularly with links and attachments. If you suspect it, report it immediately using the phishing button. Hi, I've recently been working on the doorkeeper gem which implements OAuth 2.0, in particular to improve the Client Authentication handling, and I'm noticing that the mechanisms of client_secret_basic and client_secret_post are a bit under-defined, i.e., what happens if the HTTP Authorization only includes the username part and not the password (the client_id and client_secret respectively). The specification that defines these is https://www.rfc-editor.org/rfc/rfc7591.html#section-4.2.2, and just refers back to https://www.rfc-editor.org/rfc/rfc6749#section-2.3.1 For client_secret_post, it looks like client_id and client_secret values are required, however, client_secret can be omitted if the secret is an empty string > client_secret: The client secret. The client MAY omit the parameter if the > client secret is an empty string. If the client_secret is omitted, isn't that just the `none` client authentication mechanism? There doesn't seem to be language for client_secret_basic that specifies if the password part of the HTTP Basic authentication is required, the RFC simply says: > Clients in possession of a client password MAY use the HTTP Basic > authentication scheme as defined in [RFC2617] Does that imply HTTP Basic authentication can only be used with client password (client_secret)? It feels like it'd be good to get these properly specified somewhere, as the original specification in RFC 6749 is quite vague. Thanks, Emelia Smith _______________________________________________ OAuth mailing list -- oauth@ietf.org To unsubscribe send an email to oauth-le...@ietf.org Emails aren't always secure, and they may be intercepted or changed after they've been sent. Santander doesn't accept liability if this happens. If you think someone may have interfered with this email, please get in touch with the sender another way. This message doesn't create or change any contract. Santander doesn't accept responsibility for damage caused by any viruses contained in this email or its attachments. Emails may be monitored. If you've received this email by mistake, please let the sender know at once that it's gone to the wrong person and then destroy it without copying, using, or telling anyone about its contents. Santander UK plc. Registered Office: 2 Triton Square, Regent's Place, London, NW1 3AN, United Kingdom. Registered Number 2294747. Registered in England and Wales. https://www.santander.co.uk<https://www.santander.co.uk/>. Telephone 0800 389 7000. Calls may be recorded or monitored. Authorised by the Prudential Regulation Authority and regulated by the Financial Conduct Authority and the Prudential Regulation Authority. Our Financial Services Register number is 106054. You can check this on the Financial Services Register by visiting the FCA’s website https://www.fca.org.uk/register. Santander and the flame logo are registered trademarks. Ref:[PDB#1-4B] Emails aren't always secure, and they may be intercepted or changed after they've been sent. Santander doesn't accept liability if this happens. If you think someone may have interfered with this email, please get in touch with the sender another way. This message doesn't create or change any contract. Santander doesn't accept responsibility for damage caused by any viruses contained in this email or its attachments. Emails may be monitored. If you've received this email by mistake, please let the sender know at once that it's gone to the wrong person and then destroy it without copying, using, or telling anyone about its contents. Santander UK plc. Registered Office: 2 Triton Square, Regent's Place, London, NW1 3AN, United Kingdom. Registered Number 2294747. Registered in England and Wales. https://www.santander.co.uk. Telephone 0800 389 7000. Calls may be recorded or monitored. Authorised by the Prudential Regulation Authority and regulated by the Financial Conduct Authority and the Prudential Regulation Authority. Our Financial Services Register number is 106054. You can check this on the Financial Services Register by visiting the FCA’s website https://www.fca.org.uk/register. Santander and the flame logo are registered trademarks. Ref:[PDB#1-4B]
_______________________________________________ OAuth mailing list -- oauth@ietf.org To unsubscribe send an email to oauth-le...@ietf.org
