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 > <[email protected]> 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 <[email protected] > <mailto:[email protected]>> > Date: Monday, 21 April 2025 at 17:06 > To: OAuth WG <[email protected] <mailto:[email protected]>> > 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 -- [email protected] > To unsubscribe send an email to [email protected] > 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]
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
