I’m working on a library to use OAuth 2.0 with MediaWiki, and find myself confused by the current state of non-confidential clients. The main source of my confusion is that the documentation (permalink) seems to imply that non-confidential clients don’t have a client secret, but in fact MediaWiki still generates and shows one, and it’s usable; as far as I can tell, a non-confidential client with its client ID and client secret can be used exactly like a confidential client can be used, provided you follow oauth.com’s recommendation and always use PKCE. (A non-confidential client can also be used without its client secret to some extent, but not completely: see T323855: OAuth 2.0 non-confidential clients cannot use refresh tokens.)

I can see two ways forward from the current state:

1. Fix T323855 and any other issues that prevent non-confidential clients from being used with their client IDs alone, then phase out the use of client secrets for them to avoid confusion. (A simple way to implement the last part would be to keep the client secrets around internally, but never show them to the user, by removing them from the Special:OAuthConsumerRegistration output.) This would be closer to conventional OAuth 2.0.
2. Ignore that OAuth 2.0 supports clients without a client secret, and instead document that non-confidential clients should be used just like confidential ones, using a client ID + client secret pair – their client secret just happens to be not secret at all. This requires no technical changes, just documentation updates to make it clear that you can and should use non-confidential clients this way (e.g., single-page / browser-based apps would include both the client ID and client secret in their source code or configuration, shipped to the browser and used there).

The latter approach seems easier to implement (given that T323855 is blocked on upstream), and I don’t really see any significant downsides to it; confidential and non-confidential clients would be technically equivalent, just with different social conventions around how they’re used (e.g., if a confidential client’s secret is found to have been published, OAuth admins would revoke it, but not so for non-confidential clients; note that this would require T323866 so that the admins can even tell whether the client is confidential or not). What do others think?

Relates to T234677: Support Free and Open Source software API clients with OAuth 2.0.