From IndieWeb
Jump to: navigation, search Provider Status:

IndieAuth is a way to use your own domain name to sign in to websites — it's like OpenID, but works with services you likely already use, and is much easier to setup.

IndieAuth was built to make it as easy as possible for users and for developers to start using this new way of signing in on the web, without the complexities of OpenID.

IndieAuth is an implementation of web sign-in and additional sign-in methods (email, GPG).

It works by linking your website to one or more authentication providers such as Twitter or Google, then entering your domain name in the login form on websites that support IndieAuth.

IndieAuth setup on your personal domain is a requirement for IndieMark Level 1.


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 Twitter or Facebook to provide our authenticated identities, we should be able to use our own domain names to log in to sites everywhere.

The #1 reason to setup IndieAuth is because you've found this wiki, and setting up IndieAuth will allow you to login and contribute to the community, including doing common things like:

There are also some IndieMark features that are built upon having IndieAuth support on your site (e.g. private messaging).

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 authorize users, but if a user uses an Authentication Endpoint on his/her own site, it can be a password, e-mail link, or any other authentication the AuthEndpoint provides. They prove their identity to their AuthEndpoint, the App waits.
  4. The User gets a code from the AuthEndpoint, in the form of a redirect to the App. (With this, the User gives the code to the App.)
  5. The App checks the code with the AuthEndpoint, and if the code is valid and if the User’s identifier matches the identifier the AuthEndpoint 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



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



Why is my https domain not working?

Q: Why does entering just my domain name (which automatically redirects http to https) not work in IndieAuth?

A: To log in with indieauth as a domain served over HTTPS, you have to type the whole URL, including https://, otherwise most implementations will assume HTTP, and HTTP to HTTPS redirects are considered insecure (especially important for purposes of authentication!)

Why am I getting "insecure redirect" errors?

  • If you get an error about an insecure redirect, check to see whether your silo link is going to https://yoursite which is in turn redirecting to http://yoursite. (Dreamwidth is an example of a site that does this.) If so, change the link to go directly to http://yoursite

How do I use a specific other site for my IndieAuth

See distributed-indieauth.

Is it good to delegate auth to 3rd parties

Is it good to delegate authentication to third parties like Facebook or Twitter for IndieAuth?[1]

IndieAuth only relies on third parties for ephemeral authentication, once per IndieAuth login attempt. Because the reliance is only ephemeral/transactional, the delegation is ok. It's not great, but it's ok, and certainly better than directly using (Facebook Connect) or the equivalents for other silos.

IndieAuth also provides better UI flow and fallbacks than OpenID, while re-using the OAuth flow that users are familiar with from Twitter, Github etc., so it's an incremental improvement over other open identity solutions.

What if I have more than one domain

IndieAuth requires symmetric rel=me links on your page and the OAuth provider profile page, and since most silos (like Github and Twitter) only allow you to put one rel=me link on your profile, you cannot use any one profile for multiple domains. There are a few alternatives:

  • use one account for one domain and another account for another domain.
  • use an alternative method for as many domains as you control:
    • email (via emailed one time short code for the user to enter)
    • PGP key authorization
    • TOTP

Why not use a DNS TXT record

Q: Why not allow configuring a rel=me link by adding a DNS TXT record to the domain?

A: Two reasons:

  • Usability. In order to use a DNS TXT record you would first need to be aware of how to create such an entry for your domain's DNS zone file - something most users have zero interest in or knowledge of, but you would also then need to put something like a PGP Public Key so that anyone trying to auth to your site would then be able to use to sign their request. Again, very few folks would be able to implement that.
  • Security. The main reason is that the TXT record would be a request to a different server that is not serving your domain and it would not be behind SSL. Whereas rel=me links in the HTML of a home page at least can be protected with https, even if they're not to start with.

Why not OpenID Email etc

See: Why web sign-in.

Why not WebFinger

Why not add WebFinger support to IndieAuth?

"The problem is it's too easy to not own your email address (, etc) so it's not really an "indie" identifier. The point of IndieAuth is to encourage people to own their online identity."[2][3]

Why is the IndieAuth verification response form-encoded 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

More FAQ

See Frequently Asked Questions for more FAQs.

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!

Feature Requests


Auth consumers (e.g. Andy Baio Opening the Source and The Great Auth Debate, , want to quickly allow users to to follow people and organizations they're already interested in, e.g. their lists of followings from their personal website.

  • Note: this requires a format or protocol for at least retrieving a list of followings from an indieweb site, and possibly adding to it if you decided to follow someone's events on Upcoming.
    • Which an Indie reader would/should also use both for initial reading list, and updating (writing to) when someone follows more people / orgs / sites.

For events in particular, people are likely to want to attend events with friends.

Location Information

Auth consumers (e.g. Andy Baio Opening the Source and The Great Auth Debate, , want location information for users. Knowing a user's current location is critical information for event sites, e.g. getting current city at login time (for onboarding, or showing events near you).

This could be done via a user's homepage profile h-card, or it could also use recent checkins.


Please open specific bugs and action items on the IndieAuth Github project. This page is for collecting thoughts that may not yet be action items or for things that apply to the IndieAuth protocol in general rather than the implementation.

Contact page support

Some sites (which? list examples below) have a separate /about or /contact page where they list all their other profiles with rel-me links, and then link to that separate page from their home page with rel=me. This is a valid way to support web-sign-in per the relmeauth spec.

However, IndieAuth does not currently support following one-deep rel-me links on people's sites to look for auth providers.

^^ This should refer to "", or "the implementation used on", rather than "IndieAuth" itself, shouldn't it?

Note: Crawling the second level of links will add significant time to the "scan" part of indieauth. One optimization is to only crawl a second level link if it's on the same domain as the authenticating domain. This means you wouldn't be able to have the chain -> ->, you'd have to have something like -> -> 09:08, 1 September 2013 (PDT)

  • only the latter use-case has been seen (in research) of -> ->
  • a user may use through a redirect, e.g.:
    • --redirect--> --rel=me link-->

Sites in the wild with a contact page separate to the homepage

  • Add sites you find here …
  • Julian Foad ( has rel=me links to & from a separate contact page ( which has the rel=me links to Twitter & Github.
  • Chris Roos tried (see )


  • 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.
  • TOTP method is not terribly secure compared with all other methods.'s criticism

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.

Selectively Displaying rel-me Info

Selectively Displaying rel-me Info (e.g. hiding your phone number).

Tantek points out that he would like to be able to use SMS auth on IndieAuth, but doesn't want his cell phone number public on his site. [4]

Ideally your site would know that the request was coming from an (your?) IndieAuth server, and only render your phone number if so.

This would require either

  1. some sort of pre-registration with the indieauth server so your site could verify a shared secret
  2. crypto signing with public keys so that pre-registration is not required

1 pre-registration

Here is a potential example flow.

  • Sign in once to your IndieAuth server
  • Click a "generate shared secret" button, which is some 128-bit string that the IndieAuth server stores internally on your user record.
  • You take the string and add some code like this to your home page:
    if header['IndieAuth-Secret'] == shared_secret
        echo '<link rel="me" href="tel:+15035551212">'
    which checks to see if the secret is passed in an HTTP header called "IndieAuth-Secret".

2 public key

  • The IndieAuth server publishes its public key in its own h-card like
  • When the IndieAuth server makes a request to fetch the HTML of your home page, it also adds an HTTP header which is a signature of the IndieAuth server hostname, your domain name and the timestamp. It would send three additional headers:
  • When your server gets the request for your home page, it can read the IndieAuth-server header to discover which server is making the request, then go fetch its public key.
  • It would then compute the signature of the three pieces of information and verify that the signature passed in the header matches, at which point it can render the private info.

Please document here if there is some other existing mechanism that can solve this!

potential workaround

A potential workaround is putting your phone number in a <link> tag in your HTML head so that it isn't visible to viewers of your web page. (Currently does this.) While this doesn't actually prevent a person from seeing your phone number, it is at least an unlikely place for them to look.

Better Error Handling

My experience was that I had a slight URL mismatch when I first tried to set up IndieAuth, something like an http/https goof or having a trailing slash in one place and no trailing slash in the other. Whatever the problem, it prevented sign-in. I figured out that problem, but when I tried to sign back in, I got the error:

Parameter "profile" must be one of the rel=me links in the site specified in the "me" parameter

This didn’t make any sense to me, as a novice to IndieAuth. After several failed retries, I finally realized that had cached my old URL and needed me to rescan to pick up the corrected information. Once I did that, everything worked -- Eric Meyer

Two possible fixes here:

  1. Be more aggressive about rescanning for a domain that’s never worked, or had recent errors. (Perhaps limited to certain types of errors.)
  2. Reword the error message to be less obscure and include some information about common ways to trigger the error and ways to address them.
    1. Parameter 'profile' must be ..." is a debugging message, not an error message. There is no mention of "parameter" or "profile" in any other user-facing aspect interaction of IndieAuth. This message needs to be replaced ASAP with a description in terms of what the user is doing. - Tantek 07:26, 18 September 2013 (PDT)
    2. What the heck is *actually* going wrong? I don't even know - we need to capture a technical description of the problem(s) that may be causing this message to occur so we can attempt to craft an actual actionable error message for the user. - Tantek 07:26, 18 September 2013 (PDT)

Edge Cases

What About RDFa Problems

If you use RDFa and are having problems, see rel=me: What about RDFa Problems.

To do

Want to help? See if you can contribute to one or more of the following:

Talks and Demos


See Also

Personal tools
Recent & Upcoming