itaru2622
commented
1 month ago @matthieusieben @devinivy please change the title of this PR, for easy tracking the lost of openID compatibility.
I understand that this scoping feature needs to break openID compatibility through discussions, but current title is hard to track when openID compatibility is lost, even the lost is big issue.
This PR adds support for scopes during the authorization flow. Three scopes are introduced
atproto: acts as a negotiation scope between the client and the server so that both know that this is an ATProto OAuth flowtransition:generic: This temporary scope allows to give access tokens issued through OAuth the same permissions as current "app passwords".transition:chat.bsky: Grants access to chat functionalities, as was the case for "privileged app passwords"This change also removes the compatibility with OpenID.
The reason is that although the implementation was technically OpenID compatible, ATProto identifiers are distributed identifiers. When a client relies on OpenID to authenticate users, it will use the auth provider (issuer) in combination with the identifier to uniquely identify the user. Since ATProto identifiers are meant to be able to move from one provider to the other, OpenID compatibility could break authentication after a user was migrated to a different provider. Future authentication attempts would be considered as distinct identities from the one previsouly used by the client.
The way OpenID compliant clients would adapt to this particularity would typically be to remove the issuer + identifier combination and use the identifier alone. While this is indeed the right way to handle ATProto identifiers, it requires more work to avoid impersonation. In particular, when obtaining a user identifier, the client must verify that the issuer of the identity token is indeed the server responsible for that user. This mechanism being not enforced by the OpenID standard, OpenID compatibility could lead to security issues. For this reason, we decided to remove OpenID compatibility from the OAuth provider.
Note that a trusted central authority could still offer OpenID compatibility by relying on ATProto's regular OAuth flow under the hood. This capability is out of the scope of this library.