IndieWebCamp is a 2-day creator camp focused on growing the independent web


Collecting notes here before moving them to the appropriate pages.

This page describes using IndieAuth for authentication rather than authorization. In this case, no token endpoint or Micropub endpoint are needed.



In these examples, the following URLs will be used.

The site the user is signing in to is the IndieWebCamp wiki:

The user signing in is Aaron Parecki:

In this example, Aaron has delegated authorization to an external service:

Web Sign-In Form

The site contains a web sign-in form prompting the user to enter their URL to sign in. Upon submitting the form, the site begins the auth process by discovering the user's auth endpoint.


Discovery points to the authorization endpoint by specifying a rel values on the index page.

<link rel="authorization_endpoint" href="">

TODO: What if no authorization_endpoint link can be found?

Authorization Endpoint

The authorization-endpoint is responsible for requesting authorization from the user and generating an authorization code. To start the sign-in flow, the user's browser will be directed to the authorization endpoint.



Values are shown without URL encoding for readability.

Starting the sign-in flow, direct the user's browser to the authorization endpoint with the parameters for the request. This is usually done via a Location header, but can optionally be an <a> tag with an href set to the authorization URL.

(Note: if response_type is omitted, it is assumed to be "id")

Full URI of the user's homepage
Full URI of the application's/website's home page
Full URI to redirect back when the login process is finished
Application-internal state variable; can contain anything
No scope parameter is used in this mode since the client is requesting identification only, not authorization.


The authorization server presents this information to the user, and when they approve, generates an authorization code and redirects the user to the redirect URI specified.

HTTP/1.1 302 Found


The authorization server should present an interface describing the request being made. It must indicate:

  • The client_id making the request
    • Including the name and logo if an h-card is found on the client_id URL

The Redirect URI

Redirect URI verification

why is redirect_uri separate from state?
the callback URL shouldn't be dynamic per request so that callback URLs can be registered. "state" is allowed to vary per request
why should callback urls be registered?
without registration it's easier to perform a redirect attack. more background here:
how does the client website register the callback at the server?
haven't written this part up yet, but the idea is for the client to publish its registered redirect URIs on its web page with a <link> tag
since client IDs are always URLs, it's all discoverable that way
for client_id a server can find its valid redirect URIs by looking for <link rel="redirect_uri" href=""> at

Verifying the authorization code

The site verifies the auth code by querying the authorization endpoint. To verify the auth code, the token endpoint makes a POST request to the authorization endpoint with the following values:

Content-type: application/x-www-form-urlencoded


After the authorization server verifies that the redirect_uri, client_id and state match the code given, the response will include the "me" value corresponding to the user that signed in.

HTTP/1.1 200 OK
Content-Type: application/x-www-form-urlencoded