...
We can reduce the complexity and attack surface of authentication with Synapse by utilizing OAuth 2 login flows in places where other mechanisms are currently used.
In particular, we can aim to replace usage of the API key with OAuth refresh tokens. The most common use case for the API key is to authenticate Synapse command line clients. Using refresh/access tokens in place of an API key provides a couple of advantages:
...
PKCE prevents a malicious application from hijacking an authorization code. This can occur when using a native app’s OAuth client, and the redirect URI is compromised by a malicious application observing traffic to the user agent (mobile app or web browser). In this scenario, the malicious app has the authorization code, and is in possession of the client’s credentials (if they exist), because it is a public client. Thus the malicious app now has access to the user’s account.
...
As an example, we can require that public clients utilize PKCE, among other considerations.
Open question: Can we make a breaking API change to In OAuth 2.0, the authorization server SHOULD NOT assume client type [1]. We can require client creators to specify their client type ? upon creation. This is a breaking API change, but acceptable because OAuth clients aren’t created programmatically (at least, it wouldn’t make sense if they are, since they must be manually verified to be functional). In OAuth 2.0, the authorization server SHOULD NOT assume client type [1].
Public clients may or may not be issued a secret
...