Imagine someone emails you saying "hey, I'm your cousin Alice Doe, nice to meet you!" How do you know it's true?
You could ask your uncle Bob Doe, "do you have a daughter called Alice?" That would confirm that Alice exists, but not that the person emailing you is Alice.
So you tell her "go to Bob Doe and bring me some proof that he's actually your dad".
Alice goes to Bob and says, "hey, dad! I want to prove to cousin Charlie that I'm Alice Doe." (Charlie is you.)
He writes a little note that says "Alice is my daughter, signed Bob." Alice brings you the note.
Now, anyone could've written that note. So you show the note to your uncle Bob and ask him "did you write this and give it to Alice?"
"Yes, I did."
And now you know that Alice is who she says she is.
Alice visits a website
charlie.example.com. It asks her to use her URL to login, so she types
charlie.example.com takes a look at
alice.example.com, inspecting both its HTTP response headers and the HTML source code. It finds a link defining a special relationship:
<link href="https://bob.example.com" rel="authorization_endpoint">
This points to a resource that can validate Alice's identity, just like her dad did. So the website sends Alice to her dad by redirecting her to this URL:
https://bob.example.com/? me=https://alice.example.com& redirect_uri=https://charlie.example.com/redirect& client_id=https://charlie.example.com& state=Hello,+uncle
When Alice is redirected to that URL, she should be logged in — just like her dad knew who she was, the website
bob.example.com should know who she is and that she owns
https://alice.example.com. Otherwise, anyone would be able to login as
bob.example.com asks her if she wants to confirm her identity:
She clicks "Yes", so
bob.example.com redirects her back to
charlie.example.com with a code:
https://charlie.example.com/redirect? code=Alice+is+my+daughter,+signed+Bob.& state=Hello,+uncle
The code is similar to the note Bob wrote. It should be short lived (10 minutes) and valid for only one use.
charlie.example.com receives the code and the original state. The state is used by
charlie.example.com to verify that the response is for the login Alice initiated. The
charlie.example.com website then sends the code back to
bob.example.com, and gets back a response confirming that that code belongs to
This confirms to
charlie.example.com that Alice owns
https://alice.example.com/ and she can login successfully.
Note that everything depends on
bob.example.com, the authorization endpoint, knowing that Alice is the owner of
https://alice.example.com/. It can only give out codes if Alice is logged in on
bob.example.com, If Alice is logged out, when she's redirected to
bob.example.com after trying to log in on
charlie.example.com, the authorization endpoint will not forward her back to
charlie.example.com with a valid code.
This description covers only part of the IndieAuth specification, useful for authentication. The protocol also defines scopes that can be used for granular access, for example, reading but not editing a blog post.