How is IndieAuth different from OpenID Connect

From IndieWeb

Main article: IndieAuth

This page documents the similarities and differences between IndieAuth and OpenID Connect.

Similar Goals

Adding identity to OAuth 2.0

IndieAuth uses a consistent form of user identifier: a URL

OAuth 2.0 by itself is missing some critical pieces that make it usable as an authentication protocol. (See OAuth is not an authentication protocol on In particular, OAuth by itself does not return any information about the user, even a unique user ID.

In order for IndieAuth to be useful as an authentication protocol (in addition to authorization), IndieAuth adds the concept of a unique user identifier: a profile URL. Because these URLs rely on the public web and DNS, they are guaranteed to be globally unique.

OpenID Connect also adds an identity layer on top of OAuth 2.0. Users are identified by a property, "sub" (short for subject), which can be a string of any format returned by the authorization server. There is no requirement that these user identifiers are globally unique, they are only guaranteed to be unique within the particular OpenID Connect system being used.

Different Goals

Simple identity rather than complete session management protocol

Instead of being a complete session management protocol, IndieAuth focuses on just returning the user's identifier for your application.

IndieAuth focuses on a much smaller scope than OpenID Connect. IndieAuth is answering "is the person in front of the computer in control of the URL they claim to be in control of". IndieAuth does not try to deal with session management, session lifetimes or any mechanisms beyond URL ownership.

OpenID Connect, on the other hand is trying to solve more problems such as session management, where it claims that it can return ID tokens that can also be used as a session. IndieAuth and OpenID Connect are working on solving two different problem spaces.

Decentralized identity

IndieAuth enables the user to choose where their identity is hosted.

The original goals of OpenID 1 included the ability for users to be their own identity providers, and developers to be able to consume any identities, without any prior relationships. Additionally, users could bring their own identity with them when they moved to a different OpenID provider. From the original OpenID spec:

OpenID is completely decentralized meaning that anyone can choose to be a Consumer or Identity Provider without having to register or be approved by any central authority. End User's can pick which Identity Provider they wish to use and preserve their Identity as they move between Providers.

OpenID Connect has moved away from these goals, instead treating each OpenID Connect system as its own silo. For example, Google is an OpenID Connect provider, so every Google account is an OpenID Connect identity. However, that identity is tied to Google, and there is no way to move it to a new provider to reuse it later.

IndieAuth is a decentralized identity protocol, leveraging the public web and DNS. Users' identities can be any valid URL, which is not tied to any particular service. The profile URL delegates to an IndieAuth server so that the user's website doesn't have to also handle authenticating the user itself. This is very similar to the original OpenID 1 mechanism.

Because of this difference, IndieAuth identities are portable, not tied to a service, and rely on the existing DNS to act as a global user database.

See Also