2018/Nuremberg/autoauth

Automated IndieAuth was a session at IndieWebCamp Nuremberg 2018.

Video: ▶️52:56s

Notes archived from: https://etherpad.indieweb.org/autoauth

Participants

Aaron Parecki (aaronpk.com)
Jan Sauer (jansauer.de)
Sven Knebel (svenknebel.de)
Sebastiaan Andeweg (seblog.nl)
Rosemary Orchard (rosemaryorchard.com)
Martijn van der Ven (vanderven.se/martijn/)
Sebastian (maker.sfeld.eu)
Sebastian Lasse (sl007)

Notes

IndieAuth works with a user, but is limited to that.
We're looking for a way a server can handle as an agent for the user while they are not involved. (e.g. Bob's Indiereader can fetch Alice's private feed, with some posts Bob has permission for)
sl007: ActivityPub already has some sort of a thing in place
- Aaronpk: it's a solution to a different problem
ActivityPub used HTTP-signatures, we can use that
- Aaronpk: is not a fan, wants to rely on HTTPS for the security, so people don't have to write their own crypto

Feed readers can handle requests for multiple users.
- That feed reader is not part of the user's website. It handles in name of the user.

1) we need a flow between the reader and the user. The user has to give permission (a read-managing scope) to the reader (preferrably once)
2) the feed-publisher wants to create tokens for the feed-fetching part, so it only has to verify access tokens it issued itself.
3) we want the user to be able to revoke the token given to the reader. After the revoke, the tokens issued by the feed publisher should be invalid

Some flow

Alice has a reader in which she can read Bob's private feed.
Alice's reader gets a token from Alice's reader, to get tokens on behalf of Alice.
To request Bob's private feed, Alice's reader asks Alice's auth enpoint to get a token for Bob's feed.
Alice's auth endpoint issues a code, sends it to Bob's token endpoint.
Bob's token endpoint

Device uses its access token to tell sven's authorization endpoint to go get a token for aaronpk.com
1. request includes: aaronpk.com client_id
2. response: URL and a code
Device polls the URL with the code to wait until the flow is done
sven's authorization endpoint tells aaronpk's token endpoint that the device is requesting a token for sven (includes: me, own client_id, client_id of device [audience?], randomly choosen auth code, callback url)
aaronpk token endpoint verifies auth code with auth endpoint discovered from me-url. if successful, calls callback to authorization endpoint confirming this
device poll succeeds, gets token
auth endpoint can revoke token, since it has a copy of it and knows where it is from

question: is it always polling, or callback an option?

headline for requests

1

1. User logs into reader app. Grants scope "request_token:read" (which gives the right to request tokens that contain a read scope)

2

2. Request from reader to auth endpoint:

response_type=external_token - Indicates to the authorization server that this is a request to create a token from some third party
me - The profile URL for the user the app is making the request at
client_id - The client URL
target_url - url the token is intended for (needed for discovery of token endpoint.)
maybe realm
response_url - The URL for a callback. (Optional for polling purposes.) (keep calling it redirect_url?)
state - A parameter set by the client which will be included when the callback is made. If polling, used as the polling key( or not required and secret in url?)
scope - (optional) A space-separated list of scopes the client is requesting, e.g. "create". If the client omits this value, the authorization server MUST use a default value. (default: grant all in token?)
Has to include "Authorization: Bearer TOKEN"

3

3. Authorization Endpoint creates an Authorization Code

4. Authorization Endpoint posts a Token request to token endpoint from target_url

grant_type=authorization_code //TODO: change, what's a good name?
code - The authorization code received from the authorization endpoint in the redirect
client_id - The client's URL (the client here is the auth endpoint sending the request)
client_client_id (stupid name) - the application for which the token is intended
redirect_uri - The client's redirect URL, which MUST match the initial authorization request.
me - The user's in which name the token is requested profile URL

Notes from Dinner

Notes from post-camp discussions over dinner

Martijn van der Ven

Post Dinner Notes

WWW-Authenticate [1]
- “A server MAY generate a WWW-Authenticate header field in [non 401] response messages to indicate that supplying credentials (or different credentials) might affect the response.”
- Can be used to communicate that different results may be returned for including a bearer token in the request.
Authentication scheme registry [2]
- For WWW-Authenticate to request authentication per the IndieAuth standard, IndieAuth should be registered as a possible scheme.
- It doesn’t look like IndieAuth has any issues with the points that need consideration before registration.
Protection Space [3]
- The official name for a group of resources that accept the same authentication. This way a service like a reader wouldn’t need separate tokens for each feed, if those feeds fall within the same protection space.
- A protection space is a combination of the canonical root URL (the scheme and authority component) of the website being accessed, and an optional realm value.

even later notes

comparison to User-Managed Access (UMA) Profile of OAuth 2.0

UMA talks about a lot of process we assume to be "implementation detail" above
- e.g. we do not model the resource owner, we do not discuss (yet) how resource server and authorization server talk to each other.
- UMA has the concept of a "permission ticket" to which an actual authentication token is bound
- when the client first accesses the protected resource, the resource registers information about this request with the auth server. The client then talks to it and references this registered information through the ticket ID, instead of repeating it. This probably exists so the resource can give the server information about how the permissions are supposed to work internally that the client doesn't know about? If we want to be able to split token endpoint (in our case) and protected resources through a protocol, do we need this too?

UMA assumes the client (that's representing the requesting party) has a way to authenticate to the authorization server, but does not describe it outside a mechanism to require human authentication (by returning a url as "please pass this to your human and have them authenticate"). THIS is the core part of the above algorithm, where the requesting parties authorization endpoint can complete an authentication on it's own to provide this. (although we use the token endpoint instead of authorization server.)
- Section 3.5 says
  The client has acquired an AAT (as defined in Section 1.3.2) from the authorization server. The exact means by which the client acquires the AAT are out of scope of this specification.

implementation notes from IWC Berlin 2018

Design decision: we'll require a link *header* pointing to the token endpoint, not <link> tags.
step 5 from Nürnberg Dinner Document has a grant_type=authorization_code
WWW-Authenticate should not be present in responses that are authenticated
Step 7 from Nürnberg Dinner Document is *not* equivalent to Authorization code verification in the IndieAuth spec - the url parameter is callback_url, not redirect_uri
- TODO: callback_url or callback_uri? - using callback_url for now
- later: callback_url seems clearly the better choice
  - it appears callback_uri was a term in OAuth 1 - not duplicating it might even help avoid confusion
  - it's always an URL
  - PayPal and WeChat appear to use it to register a URL that receives callbacks about sueccessful payment etc (IPN) [4], which is also unrelated
  - tons of people appear to use the term "callback_uri" when they mean "redirect_uri", including tons of code samples. might oauth1 legacy again.
  - or OAuth2 drafts - https://www.ietf.org/mail-archive/web/oauth/current/msg01943.html
Demo on YT