(Redirected from login-brainstorming)
IndieAuth is a protocol to log users into web applications through an authorization server. The authorization server is linked from the user's home page.
Creating an Authorization Endpoint
An authorization endpoint must be able to both generate authorization codes as well as verify authorization codes.
Every endpoint MUST return a
HTTP header in all responses.
It is used to verify that it's really an endpoint.
1. Login 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.
2. Endpoint Discovery
The web application checks the user's website for a link with a rel-value of "authorization_endpoint":
<link rel="authorization_endpoint" href="http://indieauth.example.org/">
Use this URL as endpoint for processing.
TODO: MUST HTTP header links be supported?
Directing the user's browser to the auth endpoint is usually done via a HTTP
Note: Values are shown without URL encoding for readability.
https://auth.example.org/auth ?me=https://aaronparecki.com/ &client_id=https://webapp.example.org/ &redirect_uri=https://webapp.example.org/auth/callback &state=1234567890 &response_type=id
4. Verify user
The authorization server should present an interface describing the request being made. It must indicate:
TODO: Example. See h-x-app.
Redirect URI verification
5. Redirect to web application
The authorization server presents the request information to the user, and when he approves, generates an authorization code and redirects the user to the redirect URI specified.
HTTP/1.1 302 Found Location: https://webapp.example.org/auth/callback ?code=xxxxxxxx &state=1234567890 &me=https://aaronparecki.com/
6. Token verification
The web application finally queries the authorization endpoint to verify the auth code given by making a POST request with the following values:
POST https://auth.example.org/auth Content-type: application/x-www-form-urlencoded code=xxxxxxxx &redirect_uri=https://webapp.example.org/auth/callback &client_id=https://webapp.example.org/ &state=1234567890
After the authorization server verifies that redirect_uri, client_id and state match the code given, the response will include the "me" and optionally the "scope" value:
HTTP/1.1 200 OK Content-Type: application/x-www-form-urlencoded me=https://aaronparecki.com/ &scope=post
Using an Authorization Service
You can use an existing authorization service such as indieauth.com if you don't want to build your own authorization service.
Why are auth codes verified with a POST instead of a GET
If auth codes are sent as a GET request in the query string, they may leak to log files or the HTTP "referer". The decision was made by the OAuth 2.0 working group to use POST requests and the HTTP Authorization header for sending these sensitive tokens and auth codes.
No, the authorization code must not be used more than once. If the code is used more than once, the authorization server must deny the request. A maximum lifetime of 10 minutes is recommended for the authorization codes, although many implementations have a lifetime of 30-60 seconds.
No, but you can use the "state" parameter to encode or reference additional application-specific parameters. The state parameter will be passed around and was designed for this purpose as well as to prevent CSRF attacks.
Does the auth server have to support the state parameter
Yes, the state parameter can be used by the client to maintain state between the request and the callback, so the auth server must support it. It is also used to prevent CSRF attacks.