IndieAuth Ticket Auth

From IndieWeb
(Redirected from User:IndieAuth Ticket Auth)
Jump to: navigation, search

Use-cases

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
  • ...

Brainstorming

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.

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.

Notes

Advantages:

Token Issuing

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.

aaronpk-ticket-admin.png

Open questions

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 https://example.com/alice/feed)

  • 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