RE: https://mastodon.social/@mcc/116047636625672758

I can quite firmly say that this isn't the case anymore. AT Protocol's OAuth had a bit of a rocky start because of permissions, but permission sets are now pretty much generally available.

Basically this was a UX issue where users believed an app password was more secure than OAuth.

But now more and more AT Protocol applications are using OAuth since they can request granular access that way. i.e., "I want to just write into this specific collection or call these specific XRPC endpoints" is now a thing.

https://atproto.com/specs/permission

AT Protocol doesn't use OIDC, because OIDC doesn't make a whole lot of sense in decentralized applications — there are parts that do, but also parts that don't. For example, what do you return for the profile response when there is no global "profile"?

OIDC also mandates JWTs in places where it may not make sense to use them (e.g., ID Tokens are JWTs as are refresh tokens in OIDC)

AT Protocol is however implementing OAuth 2.1, which incorporates many security considerations.

I think we can probably borrow both the prompt, login_hint and id_tokens from OIDC, but I don't think full OIDC would actually make sense here.

It's just like how Mastodon now borrows some ideas from OIDC whilst not fully doing OIDC. (see the profile scope and userinfo endpoint)

OIDC works well in more centralized systems, OAuth 2.1 with DPoP works better for decentralized systems.