-
Type:
New Feature
-
Resolution: Unresolved
-
Priority:
Normal
-
None
-
Affects Version/s: None
-
Component/s: Website
-
None
"public" OAuth clients, as defined in RFC 6749 Section 2.1 are ones where the client is "incapable of maintaining the confidentiality of their credentials (e.g., clients executing on the device used by the resource owner, such as an installed native application or a web browser-based application)"
Some examples of clients which fit this description are MusicBrainz Picard, MusicBrainz and ListenBrainz mobile applications, and external staticly hosted SPA utilities like MagicISRC.
For a description of how the authentication flow for these types of apps should be implemented in order to be secure, see:
Some particular details that I think are worth noting:
- "public" clients should not be required to provide a client secret during the authentication flow (RFC 10017 specifies "MUST NOT" for web browser based apps, but the wording is a bit unclear) and the authentication provider should check, but not trust, the secret if one is sent.
- a redirect url must be specified in the app registration, and must be checked for an exact match by the oauth provider. RFC 8252 Section 7 has some recommendations for redirect urls for native apps. (Private-use URI scheme is likely appropriate for Picard and phone apps.)
- CORS needs to be supported on all oauth endpoints in order for browser-based oauth to work.
- Refresh tokens should be invalidated once they have been used (and a new refresh token issued), and should expire after some reasonable amount of time if unused (note that this will force people who only occasionally use an app to re-authenticate)
It's possible that the MetaBrainz oauth implementation does already meet all of the requirements needed to support "public" apps (aside from not allowing apps to authenticate without providing a client secret, though this could be considered optional). If this is the case, the documentation should be updated to make this clear.
Note that according to the documentation as written, Picard is currently in violation (as it is shipping the oauth client secret to the user's machine as part of the native app install).