IndieAuth – Turn Your Personal Domain Into An OAUTH Provider

From IIW

Session Topic:IndieAuth: Turn Your Personal Domain Into An OAuth Provider

Tuesday 4H

Convener: Aaron Parecki

Notes-taker: Kevin Marks & Ben Werdmuller

Discussion notes, key understandings, outstanding questions, observations, and, if appropriate to this discussion: action items, next steps:

Find notes from this session here: http://indiewebcamp.com/2014-05-06-iiw-indieauth


Further Notes Steve Williams:

is indieauth what I used to log into the wiki? @aaronpk: yes @sbw: I have a bug report

Aaron Parecki:

if you have signed into indiewebcamp.com you have used indieauth already

If you link from your site to and form a silo with rel="me" that is relMeAuth -you delegate authentication to a silo

this lets you use your own domain as the identifier, but other sites as authentication

indieauth.com is a little confusing as it is doing two things

indieauth.com came from wanting to add relMeAuth to mediawiki on indiewebcamp.com

instead of getting down in mediawiki code to add auth, I made indieauth.com do to auth as service

by making indieauth.com a service, I could add a small plugin to mediawiki to talk to indieauth

I initially didn't expect anyone else to use indieauth.com originally

one of the things that OAuth2 did different from OAuth1 was separating auth as an internal service

after I made it work with the wiki, I made it work with my own site hosting p3k


we need to find an OAuth2 provider agreed on between indieauth and the user

I had the same problem with posting to my own site - I needed authZ to post to my own site

http://ownyourgram.com/ is a way to post to your micropub endpoint when you send photos to instagram

as OAuth2 doesn't specify discovery, we have OpenID Connect, and no other spec.

I used rel=authorization-endpoint and rel=token-endpoint from existing specs and made up rel=micropub

one of my goals is to avoid crypto and rely on TLS like OAuth2 did (it seemed like a good idea at the time)


Kevin Marks:

well, the SSL code has had a lot of people look at it closely recently

[Justin Richer http://www.justin.richter.org]: @aaronpk should look up token introspection as an OAuth spec (which I wrote) - similar to IndieAuth token factoring

Aaron Parecki:

indieuath can be an internal part of the wiki, or it can be service that the user's micropub site uses

Justin Richer :

UMA is a protocol built on OAuth2 and OpenID connect to introduce the client to the auth services

there's a lot of potential synergy between UMA and what the Indieauth delegation is trying to do

there is a profile of OpenID Connect that lets you defer verifying the signature, but implementations do it anyway

what if you don't have an HTML parser?

Kevin Marks:

we have an HTML parser service in the cloud that will make it into JSON for you #indieweb

Received from Ben Werdmuller:

Notes by Ben Werdmuller These are permanently hosted at: http://indiewebcamp.com/2014-05-06-iiw-indieauth

If you have signed into the indiewebcamp.com wiki, then you've already used IndieAuth. In this session, Aaron will get into the guts of it.

RelMeAuth: Your site <----> Multiple silos

Your domain is the identifier for the thing you're logging into; you're delegating the actual authentication to a third-party service (e.g. a service)

E.g., aaronparecki.com logs in using RelMeAuth using Aaron's GitHub account (github.com/aaronpk) to actually do the authentication.

Aaron apologizes for a slightly confusing indieauth.com site.

Initially, he wanted to write authentication for the indiewebcamp.com wiki. MediaWiki has a very convoluted codebase, and he was dreading diving into it. He knew that for every new authentication method he had to add, he'd have to do it all again. So instead he decided to write the integration code once, using indieauth.com as an integration point, and write all of the other authentication integrations for indieauth.com, which had a much cleaner codebase (as he was starting from scratch).

The integration mechanism is OAuth-like.

There is some discussion between Justin Richer at MITRE and Aaron Parecki about whether the indiewebcamp.com authentication mechanism is effectively siloed authentication. Aaron defended on the basis that OAuth 2.0 explicitly featured the ability to separate the auth service from identity. (It's a tactical decision to have a proprietary link between indiewebcamp.com and indieauth.com, although it's a little more exposed because the communication happens over HTTP. Justin notes that it would be better to use existing authentication protocols that are designed for security.)

Aaron discusses using IndieAuth with micropub, an API for using third-party apps to post to indieweb sites. The micropub-compatible app needs to be able to log into your personal site.

OwnYourGram.com: you log in via IndieAuth, authorize the app, and it reads your Instagram feed and autoposts it to your indieweb site using micropub.

  • [me] -> (rel) -> [authorization endpoint]
  • [me] -> (rel) -> [token endpoint]
  • [me] -> (rel) -> [resource server, micropub]

Aaron took authorization & token endpoints from OAuth / OpenID connect; micropub is new.

A question came up about why this uses HTML vs using a .well-known address. The answer is that it's easier to code on a wider variety of platforms.

A further issue was brought up re: OAuth separating authorization and token endpoints, which is not something that is actually supported in OAuth. Aaron points out that you _can_ have them on separate servers, as long as they are tightly coupled - as is the case here.


Aaron: "avoid crypto". He likes the idea of signed tokens, but nobody can agree on the signing mechanism. Conversations tend to disappear down unproductive rabbitholes .....


Aaron discussed the OAuth workflow and how it relates to IndieAuth. IndieAuth assumes clients that have a web presence. It can be an internal part of the indieweb site, or it can be an adjacent service that the site delegates to.