OAuth is the foundation of most of modern online security, used everywhere from signing in to mobile apps to protecting your bank accounts.
This session will cover what’s new in OAuth 2.1 and how ActivityPub can take advantage of some of the newest features of OAuth to better support a wide range of interoperable ActivityPub clients.
I really appreciate the slimming down in OAuth 2.1 and learnt a lot about PKCE (and how to pronounce it) and IndieAuth.
IndieAuth (by using URL as client_id) and PKCE both solve problem of client registration. PKCE seems to be the more modern (and secure) way of doing this. Are there plans for IndieAuth v2 with PKCE?
IndieAuth does authorization endpoint discovery by GET/HEAD request to the user profile. OpenID Connect Discovery does this via WebFinger and a special relation. Given how WebFinger is already widely used in ActivityPub implementations and almost a de-facto requirement for federation, would it make sense to use WebFinger like OpenID Connect?
I think a definite document specifying how authentication/authorization should be implemented on the Fediverse would be immensely helpful. Would you suggest just agreeing on IndieAuth or writing up something new (IndieAuth v2 or FediAuth)?
Client registration does a couple things. One part is the security gained by the client being able to authenticate, the other is providing metadata about the client such as the application name and logo.
IndieAuth skips the need for client registration for metadata purposes by using URLs as client IDs and having the metadata published at that URL. PKCE is still a necessary step to provide an alternative to the authentication part of client registration. In fact, the latest version of the IndieAuth spec recommends that clients also use PKCE! There isn’t a need for a v2 spec because PKCE can be added to existing OAuth systems in a backwards compatible way, which was one of the design goals of PKCE.
Interestingly, ActivityPub doesn’t actually need Webfinger, and in fact one of the principles of the W3C SocialCG (where ActivityPub was developed) was to take a “follow-your-nose” approach to spec design, which specifically avoids approaches like Webfinger with hardcoded URLs. Personally I’d love to see ActivityPub drop Webfinger in favor of discovery methods that don’t rely on hardcoded URLs, but that’s a different discussion.
Creating an maintaining a spec is not a small undertaking, I wouldn’t recommend creating something new if at all possible. Over the years, we’ve been trying to make IndieAuth closer and closer to plain OAuth 2 so that it has less functionality that is different, just to make it easier to understand and maintain.
I’m pretty sure it would be possible for a developer to pick up IndieAuth and use it with ActivityPub clients and servers today exactly as written!