Proposed Changes to IndieAuth Protocol
Published on 2015-03-04 | Last modified on 2015-03-06
Update (2015-03-06): Aaron Parecki replied to this proposal here. I agree with his reply as it turns out IndieAuth is also used for authorization in addition to authentication.
This post proposes a few minimal changes to the IndieAuth protocol as well as their rationale. These changes were inspired by creating an alternative but mostly compatible IndieAuth implementation called IndieCert, using client certificates to authenticate users, or actually browsers. More information on IndieCert can be found in this blog post.
Currently the protocol expects the use of the
parameter in the authentication request. This does not seem necessary as it
is never used, just a remnant of OAuth 2.0. The
enough to establish the relying party’s identity. So the proposal is to make
client_id support OPTIONAL both for relying party as well as the
It is advisable to implement CSRF protection. The
can be used for that, or a new parameter, like
proposed by “SaferWeb: OAuth2.a or Let’s Just Fix It” MUST be implemented.
This will protect against an attacker obtaining a
tricking the user’s browser to go to the relying party’s callback endpoint,
thus gaining access to the server on the attacker’s behalf and potentially
leaking private data to the attacker’s account.
The CSRF token (or state) needs to be saved in a browser session that is created when the user tries to login to the relying party. The CSRF token is compared to the token specified on the callback URL after the user grants permission to the relying party to obtain the user’s identity.
Terminology: authentication instead of authorization
IndieAuth is actually used for authentication and not
authorization as is mentioned on the “Distributed IndieAuth” page.
This should be modified to talk about authentication instead. Also the name of
authorization_endpoint should be changed to
Additional “verify” endpoint
The “auth” endpoint in IndieAuth is currently used both for initiating the authentication (GET) as well as verifying the authentication code (POST). In order to support the option to ask for user consent before the identity of the user is released, it makes sense to have a separate verification endpoint as the POST on the authentication endpoint will be used for a form submit.
This is also relevant in the case of “Distributed IndieAuth” where the
user mentions the
authorization_endpoint, as a link relation on
their home page. The proposal is to also allow for (optionally) defining a
verification_endpoint link relationship on the user’s homepage.
<link rel="authentication_endpoint" href="https://indiecert.net/auth"> <link rel="verification_endpoint" href="https://indiecert.net/verify">
Content negotiation for “verify” endpoint
Currently the IndieAuth protocol uses a
application/x-www-form-urlencoded formatted response
instead of the currently more popular
format, e.g. in OAuth 2.0. It is proposed to support “Content Negotiation” by
checking the HTTP
Accept header in the verification request and
application/json depending on the
Accept header. The
default can be either of those, but both MUST be supported.