IndieAuth Provider #5

Open
opened 3 years ago by malacoda · 3 comments
malacoda commented 3 years ago
Owner

IndieAuth is a decentralized identity protocol built on top of OAuth 2.0. Identities are HTTP URIs which delegate to an IndieAuth provider. Badger Who Server should be able to act as an authorization_endpoint for the Authentication Flow with any compatible IndieAuth client. Note that Badger Who Server cannot grant authorization to clients (as it is only an identity provider), and so will not implement the token_endpoint for the Authorization Flow.

If the user already has a URI that they can control, this may be preferred over the Badger OpenID Connect protocol, as it is a W3C spec. However, Badger OIDC is used if the user prefers to authenticate directly as an identity on the Who Server.

It's in scope for phase 1 to act as both a provider and consumer (#13) of this protocol.

[IndieAuth](https://indieauth.net/) is a decentralized identity protocol built on top of OAuth 2.0. Identities are HTTP URIs which delegate to an IndieAuth provider. Badger Who Server should be able to act as an `authorization_endpoint` for the [Authentication Flow](https://indieauth.spec.indieweb.org/#authentication) with any compatible IndieAuth client. Note that Badger Who Server cannot grant authorization to clients (as it is only an identity provider), and so will not implement the `token_endpoint` for the Authorization Flow. If the user already has a URI that they can control, this may be preferred over the Badger OpenID Connect protocol, as it is a W3C spec. However, Badger OIDC is used if the user prefers to authenticate directly as an identity on the Who Server. It's in scope for phase 1 to act as both a provider and consumer (#13) of this protocol.
malacoda added this to the Phase I milestone 3 years ago
Poster
Owner

Note that this ticket was originally about implementing the protocol used on indieauth.com/indielogin.com which is somewhat generically referred to as "web sign-in protocol". The current IndieAuth protocol as far as I can tell appears to be an evolution of the indieauth.com protocol. The intention was originally for users to be able to use Who Server as a drop-in replacement for web sign-in services for clients that wished to support it, with the added bonus of being able to use any of Who Server's other supported identity protocols (in other words, like so).

I feel that's still a worthy goal although it's probably orthogonal to using Who Server as an authorization_endpoint. I'd need to consider the practicality of this, though - what if, for example, someone attempts to log in to (e.g.) auth.hydrocitynet.org as https://sterling.archer.name while also using auth.hydrocitynet.org as the authorization_endpoint? The Who Server would probably need to be smart enough to recognize and avoid attempting to use IndieAuth on such identifiers.

Note that this ticket was originally about implementing the protocol used on [indieauth.com](https://indieweb.org/indieauth.com)/[indielogin.com](https://indieweb.org/indielogin.com) which is somewhat generically referred to as "[web sign-in protocol](https://indieweb.org/web-sign-in-protocol)". The current IndieAuth protocol as far as I can tell appears to be an evolution of the indieauth.com protocol. The intention was originally for users to be able to use Who Server as a drop-in replacement for web sign-in services for clients that wished to support it, with the added bonus of being able to use any of Who Server's other supported identity protocols (in other words, [like so](https://indielogin.com/api)). I feel that's still a worthy goal although it's probably orthogonal to using Who Server as an `authorization_endpoint`. I'd need to consider the practicality of this, though - what if, for example, someone attempts to log in to (e.g.) `auth.hydrocitynet.org` as `https://sterling.archer.name` while *also* using `auth.hydrocitynet.org` as the `authorization_endpoint`? The Who Server would probably need to be smart enough to recognize and avoid attempting to use IndieAuth on such identifiers.
Poster
Owner

The most likely implementation of an IndieAuth provider would be to simply run remote authentication using the me value as the identifier. Since the me value is guaranteed to be an HTTP URI, and is most likely not one natively supported by us (otherwise why use IndieAuth?), the most practical effect is that it ends up basically being RelMeAuth with extra steps.

On one hand, we already plan to support RelMeAuth natively! On the other hand, it looks like IndieLogin.com will delegate to an IndieAuth server, so it would be possible to rel-me link to a profile not supported natively by IndieLogin.com and it will delegate to Who Server to successfully authenticate (and vice-versa, allowing Who Server to delegate to IndieLogin.com for Silo links, and removing the requirement for individual Who Server instances to register as an "app" to each Silo).

The most likely implementation of an IndieAuth provider would be to simply run remote authentication using the `me` value as the identifier. Since the `me` value is guaranteed to be an HTTP URI, and is most likely not one natively supported by us (otherwise why use IndieAuth?), the most practical effect is that it ends up basically being RelMeAuth with extra steps. On one hand, *we already plan to support RelMeAuth natively!* On the other hand, it looks like IndieLogin.com [will delegate to an IndieAuth server](https://indielogin.com/setup#indieauth), so it would be possible to rel-me link to a profile not supported natively by IndieLogin.com and it will delegate to Who Server to successfully authenticate (and vice-versa, allowing Who Server to delegate to IndieLogin.com for Silo links, and removing the requirement for individual Who Server instances to register as an "app" to each Silo).
Poster
Owner

It goes without saying that logging into Who Server with the authorization_endpoint pointing to another Who Server will have the same effect as going to that other Who Server and authenticating there.

It goes without saying that logging into Who Server with the `authorization_endpoint` pointing to another Who Server will have the same effect as going to that other Who Server and authenticating there.
Sign in to join this conversation.
No Milestone
No Assignees
1 Participants
Notifications
Due Date

No due date set.

Dependencies

This issue currently doesn't have any dependencies.

Loading…
There is no content yet.