My interpretation of RFC 6749 is that the client_id is not secret, regardless of source code license. Section 2.2 says "The client identifier is not a secret; it is exposed to the resource owner and MUST NOT be used alone for client authentication." So I'm not sure if there is any special problem we need to solve here.

In T234677#5655125, @tstarling wrote:

My interpretation of RFC 6749 is that the client_id is not secret, regardless of source code license. Section 2.2 says "The client identifier is not a secret; it is exposed to the resource owner and MUST NOT be used alone for client authentication." So I'm not sure if there is any special problem we need to solve here.

Thanks for the note. I updated it to point out that the client ID/client secret pair needs to be kept secret, not the ID itself.

I think the state of the art is to not provide a client secret for Open Source, native, or browser-based clients. https://aaronparecki.com/oauth-2-simplified/#creating-an-app

My understanding is that this task is mostly done, because MediaWiki nominally supports non-confidential clients now: you can indicate at consumer registration time whether a client should be confidential or not, and non-confidential clients can get an access token and make authenticated requests based on only their client ID, without using the client secret.

That said, there’s at least one remaining issue with non-confidential clients (T323855: OAuth 2.0 non-confidential clients cannot use refresh tokens), and also, MediaWiki still generates a client secret for non-confidential clients (contrary to the “state of the art” mentioned above), which is confusing: I’m seeking some clarification in T323867: Clarify use of non-confidential OAuth 2.0 clients.