From IndieWeb
Jump to: navigation, search

IndieAuth is a way for doing Web sign-in, where you use your own homepage to sign in to other places.

IndieAuth was build on ideas and technology from existing proven technologies like OAuth and OpenID but aims at making it easier for users as well as developers. It also decentralises much of the process so completely separate implementations and services can be used for each part.

Note: IndieAuth is often conflated with the service provider. The first is the subject of this page: the way login works. The second is an implementation that most people will be familiar with because it is used on this wiki.

Work to address this naming issue is discussed below.


IndieAuth is part of taking back control of your online identity. Instead of logging in to websites as “you on Twitter” or “you on Facebook”, you should be able to log in as just “you”. We should not be relying on silos to provide our authenticated identities, we should be able to use our own personal domains to log in to sites everywhere.

You can use it right now to log in to this wiki and contribute to the community, including doing common things like:

IndieAuth is also used by many Micropub clients, so you can use your own website to log in to the tools you use to post content.

How it works

Basic flow with a User signing in to a (web)App

  1. The User fills in his/her personal URL This is called Web sign-in.
  2. The App fetches the URL, looking for an Authorization Endpoint. For this, the user can use, but it can also be at their own domain. The App redirects the User to their AuthEndpoint.
  3. The User authenticates at their own Authorization Endpoint. uses RelMeAuth to authenticate users, but if a user uses an Authorization Endpoint on his/her own site, it can be a password, e-mail link, or any other authentication the auth endpoint provides. They prove their identity to their auth endpoint, the App waits.
  4. The authorization endpoint issued a temporary authorization code, and sends it to the app by redirecting the user's browser.
  5. The App checks the code with the auth endpoint, and if the code is valid and if the User’s identifier matches the identifier the auth endpoint gives, the login is completed, and the User can enter and use the app.

How to

Set up using

  • Add a link on your home page to your various social profiles with the attribute rel="me"
  • Ensure your profiles link back to your home page
  • Enter your domain in a "Web Sign-In" box to begin using your own domain as your online identity!

See: full setup instructions

Use for your OpenID


Setup your own IndieAuth provider

Main article: authorization-endpoint


IndieWeb Examples

Every person/site in irc-people and Special:RecentChanges has setup IndieAuth on their personal domain, since it is required to edit the wiki!


Many Micropub implementations use IndieAuth for authentication, including:

Supporting Sites

(This section is a stub and needs expansion!)

There are a growing number of web sites that you can log into using IndieAuth and gain additional functionality:


  • is an implementation of Web sign-in/RelMeAuth with an HTTP API
  • is the primary authorization server implementation used by most people currently
  • indiecert implements authentication with client certificates for https explicitly specified when entering one's web address, and only with manually setting state parameter from querystring to arbitrary value after getting "400 Bad Request", when using indieauth login.
  • allows login to IndieAuth enabled sites anonymously
  • Acquiescence is a simple IndieAuth authorization and token endpoint. It is currently limited to GitHub for authorization. Barry Frost uses Acquiescence on his website.

Table of Contents

The Service

The service lets you support RelMeAuth logins without writing all the OAuth code for each provider! It also supports a few additional non-OAuth providers such as Email and GPG.

Read the full documentation

Source Code

The source code is available on GitHub. Feel free to fork it and submit pull requests if you make any changes!


The official IndieAuth FAQ is here:

Feel free to add more questions here that seemed to be asked more than once.

Do I need a silo account

Q: Do I need an account on some third party silo to use it?

Short answer: no. You can use PGP or selfauth for example.

Longer answer: you do not need a silo account to use IndieAuth, e.g. you may set it up with PGP or selfauth.

However, the vast majority of people already have silo accounts, and most people who have their own websites already have visible hyperlinks to their silo profiles, thus the easiest way to get most people setup with IndieAuth is using RelMeAuth by adding rel=me to their silo hyperlinks, and configuring their silo profiles to link back to their personal website.

And despite using a silo, there is little downside because the use is ephemeral (the site using IndieAuth has no idea which silo used to verify your personal site identity), and there are a number of advantages for most folks:

  • UX familiarity. Most users are already familiar with the authentication flow of signing into a site or app with Twitter or GitHub (or even Facebook has a similar flow.
  • security. Silos have a much larger security staff (and with likely more expertise) than you do, and thus have likely secured their sign-in and authentication/authorization code and user flows much more than solution you would maintain yourself.
  • two-factor authentication (TFA) Most silo accounts can be secured with TFA which adds an additional degree of security, whereas the DIY IndieAuth solutions do not have such a capability, nor does anyone know of anyone who has implemented TFA on their personal site.

One potentially non-trivial downside (depends on the user) of using a silo account for authorization is that the silo account may be tracking your use of, and who knows what they will do with that data. The silo accounts do not see what services (like this wiki) that you sign-into however with IndieAuth.


This section is about issues with IndieAuth-the-building block, not Please open specific bugs and action items for the latter on the Github project. Issues below should be specifically about IndieAuth as a protocol.


  • The token can be sent to IndieAuth without TLS (or the docs make it appear so); such a request should be refused (*not* redirected) to prevent DNS poisoning, MITM, and race-condition attacks.

Need Simple Copy Paste How To

The explanation in provides a list of three lengthy descriptions of what you need to setup IndieAuth, which was then subsequently criticized as "this is not a straightforward process" in the post:

Thus we need a a simple copy paste how to that is not three lengthy descriptions.

Any explanation of how to use IndieAuth needs to start with a 1-2 sentence summary. No more.

Compare with:

Explanations for IndieAuth need to be at least as simple to understand as those for Twitter Sign-in and Facebook Connect.

IndieAuth using form-encoded responses instead of JSON

IndieAuth uses standard form-encoding for requests and response because it has been a standard encoding format since the beginning of the web. If it were a JSON response, then 7 years down the road you'd be asking "why is the response in JSON instead of ____" where ____ is the next trendy thing that replaces JSON. (Remember when XML was the new hotness?)

Proposal for content negotiation: perpetual-tripper 02:26, 5 March 2015 (PST)

  • To me this would violate Postel's law, requiring every implementation to publish many different formats. I don't care which format IndieAuth produces, but I do think we should settle on one canonical format. 10:03, 5 March 2015 (PST)
  • Agreed that there should be only one format. The only valid argument for JSON is that the OAuth 2.0 spec defines the response as JSON. Aaron Parecki 10:06, 5 March 2015 (PST)
  • OK I withdraw my objection to content negotiation. Agree it is a relatively small burden on a relatively small number of providers; it's worth supporting multiple formats for convenience to the large number of consumers 12:06, 5 March 2015 (PST)
  • Just to be anti-inventing-new-formats (too many of them around and demanding attention), I'd go for form-encoded -- Kartik Prabhu 00:21 2015-03-06
  • I just never saw HTTP POST form encoded _responses_ anywhere, only POST url encoded form requests... Any link to other (REST) services that use this? e.g. XMLHttpRequest does not support form encoded responses at all... fkooman

Requesting additional user details

The auth consumers may want to receive additional information about a user, and not just their homepage URL. Andy Baio raised some points in regard to this in a backer-only Kickstarter post, Opening the Source and The Great Auth Debate, 2015-03-16, when deciding what authenticator to use for

  • Silos may give the application access to the user’s social graph: who their friends are, who they are following.
    • This would require some IndieWeb format for following.
    • This is great for applications like readers to start a user off.
  • Silos may give the application location information about the user.
    • This is great for applications like that want to show relevant events.
    • May be possible by parsing the homepage URL of the user for h-card or recent checkins.

naming confusion

There has been ongoing confusion between IndieAuth(-the-protocol), and RelMeAuth.

Most people use IndieAuth by using as their authorization_endpoint, which then does RelMeAuth to authenticate them, which has people conflate IndieAuth with rel=me-links.

Some might also just have rel=me links set up and only log in to sites which use (or other services that support RelMeAuth directly) to handle login for them, which means they are using RelMeAuth, but not IndieAuth(-the-protocol), while thinking they are using IndieAuth.

  • One problem with the site being called just "" is that people then think that IndieAuth is somehow centralized around this service.
  • In in-person conversations about IndieAuth/RelMeAuth/OAuth with people, I've found that most people think of RelMeAuth when they are talking about IndieAuth. Aaron Parecki
    • Another possibility is to rename the IndieAuth protocol (which is an extension of OAuth 2.0) to make it clear that the OAuth 2.0 extension has nothing to do with RelMeAuth
      • Martijn van der Ven: I think renaming the protocol is your call, Aaron Parecki as the author of said protocol, but I feel it would be unnecessary. Especially if is getting renamed. This feels like an education issue, possibly a documentation issue (which we are already solving with wiki-gardening!). We don’t go and rename microformats because people have been writing blog posts where they used the word “microformats” and then described some other system like Microdata. Instead we educate on what the name microformats is.
        • sknebel: +1, I think that'd lead to even more confusion
    • Martijn van der Ven: Note that no implementers have made the mistake. Acquiescence,, Known, selfauth all talk about IndieAuth as the protocol.
      • Aaron Parecki: This is a great point, and convinces me the name of the spec is fine.
    • Martijn van der Ven: And no consumers advertise it wrong as far as I can find. Are there any implementations that use only and claim to be IndieAuth? That means not using something like indieauth/client and using the service as a fallback, but really using only the service?

      This wiki is an example of that, but also does not claim to use IndieAuth in any way! It describes its login as web sign-in and not IndieAuth. It mentions IndieAuth as an alternative for people who do not want to use their social media accounts, that’s a very correct description:


      • sknebel Indeed, web-sign in seems like a fitting term here (given that the definitions talk about the general concept of using your homepage URL to sign in, and reference both RelMeAuth and IndieAuth as implementations)
    • sknebel I've been explaining IndieAuth at HWC Berlin to people from "has written an endpoint following authorization-endpoint" over "has logged into the wiki" to "IndieAuth, never heard of it". One of the first category wasn't quite clear on the status of implementations of sites to log-in to (since they'd only used it with sites using, primarily the wiki), second wasn't necessarily aware of a difference between service and protocol. Explaining the difference (and how RelMeAuth fits in) wasn't an issue, but had to be explicitly mentioned. I believe a different name for would go a long way there.
  • The wiki pages for IndieAuth don't always make this distinction clear, work has begun during IndieWebWeek (2017-05) to improve this
    • Work continued 2017-07-19 by moving FAQ and Issue items from this page to the pages they were about: RelMeAuth or
    • New copy for this wiki page was written in a separate sandbox page where the focus was on explaining IndieAuth and its 3 parts. See martijn/IndieAuth.
      • sknebel +1, to me this is just clarifying and extending existing documentation (e.g. the different endpoints, that currently only have their separate pages, and clearly separating .com from the protocol)

how to should include endpoint definition

This would make sure first time users do not have to try and figure this out themselves. Example:

Getting myself validated through IndieAuth was already taken care of by the rel="me" links, but some services needed me to declare IndieAuth as my authorization endpoint; […]

Here “IndieAuth” refers to The discussion above is about clearing up the name issue, this is only about including the endpoint declaration in HTML. Daniel ran into services that offered him to login with IndieAuth and required him to declare the authorization endpoint, completely according to how IndieAuth works. (As documented above, most implementers stick to the spec when they talk about IndieAuth.) This is currently completely left out of the how-to and new users are left to figure it out for themselves.

The wiki leaves users hanging who try to login using IndieAuth outside of the wiki. This how-to issue is documented here specifically because Tantek Çelik wondered why an extra step was needed.

  • I say this is a mistake in the How-to that needs to be addressed. — Martijn van der Ven
  • agreed, instructions about IndieAuth should explicitly include the endpoint —sknebel
  • -1 disagreed. Don't make more work for the >99% to satisfy the <1% who want to install their own IndieAuth providers. IndieAuth authentication services should handle rel=me without needing an explicitly specified endpoint. - Tantek Çelik

To do

Talks and Demos

See Also