IndieAuth Ticket Auth
Use-cases that inspired the development of this protocol:
- be able to fetch private posts from someone's feed
- don't rely on a "follow request" in order to do so
Step 1: Decide to issue an access token
Bob would like to notify Alice that Bob is following Alice so that Alice can choose to share more things with Bob.
- TODO: this could be a follow post, or some other protocol, but is not related to authentication
This step isn't strictly necessary but may provide a better user experience for granting these tokens.
This is in contrast to a mechanism of advertising the fact that there may be private/protected content at a URL by using something like a WWW-Authenticate header. By indicating there may be more to see at a URL, that itself is leaking information.
Step 2: Issue an access token
Alice has decided to send an access token to Bob. (Either because Alice decided to out of the blue, or because Alice noticed Bob's follow notification.)
Create the IndieAuth ticket
Alice generates a short-lived ticket which will last approximately a minute at most.
- Feed URL = https://alice.example.com/
- Ticket = 32985723984723985792834
- Deliver to ticket endpoint of: https://bob.example.org/
Discover ticket endpoint of https://bob.example.org/
Post ticket to https://auth.example.org/ticket
curl https://auth.example.org/ticket \ # a random string that can be redeemed for an access token -d ticket=32985723984723985792834 \ # the access token will work at this URL -d resource=https://alice.example.com/ \ # the access token should be used when acting on behalf of this URL -d subject=https://bob.example.org/
This is basically saying "if you wanted to fetch this feed as this person and see private stuff, here's a ticket you can use to get an access token".
Redeem the ticket for an access token
Bob's ticket endpoint redeems the ticket for an access token
Fetch resource https://alice.example.com/ to discover token endpoint
curl https://alice.example.com/token -d grant_type=ticket -d ticket=32985723984723985792834
Response is an access token
Step 3: Use the access token
Now Bob's authorization endpoint has the remote access token that could be used to fetch Alice's feed.
How to get it to the reader or the webmention endpoint verifier is up to those implementations, it may be internal, or may use another spec to coordinate.
- The thing that gets tokens only needs one new public endpoint, the endpoint that receives tokens
- Issuing tokens is completely voluntary, and does not have to be prompted by an action by the eventual receiver of the token
How a website decides to issue tokens does not need to be defined by this spec.
Aaron Parecki created an interface to be able to send tickets to arbitrary URLs, and shows the token info after the ticket has been redeemed.
Would a token grant access to anything more specific than the provided resource, or would it be only for that specific resource? (e.g. should a token for
https://example.com/alice/ also work on
- Giving meaning to the URLs like this is convenient but may be misleading or break security boundaries in unexpected ways.
- An alternative would be to include another parameter, such as the previously discussed "realm", or somehow using scopes for this.
- TODO: look at the OAuth Resource Indicator spec to see if they have solved it some way
Any provision for providing an expiry time as part of the granted ticket?
- What would the use case be? Just like OAuth authorization codes, these are extremely short lived and there is no recourse if they expire other than starting over