IndieAuth

From IndieWeb
Jump to: navigation, search

IndieAuth is a way for doing Web sign-in, where you use your own homepage to sign in to other places.

IndieAuth was build on ideas and technology from existing proven technologies like OAuth and OpenID but aims at making it easier for users as well as developers. It also decentralises much of the process so completely separate implementations and services can be used for each part.

Note: IndieAuth is often conflated with the IndieAuth.com service provider. The first is the subject of this page: the way login works. The second is an implementation that most people will be familiar with because it is used on this wiki.

Work to address this naming issue is discussed below.

Why

IndieAuth is part of taking back control of your online identity. Instead of logging in to websites as “you on Twitter” or “you on Facebook”, you should be able to log in as just “you”. We should not be relying on silos to provide our authenticated identities, we should be able to use our own personal domains to log in to sites everywhere.

You can use it right now to log in to this wiki and contribute to the community, including doing common things like:

IndieAuth is also used by many Micropub clients, so you can use your own website to log in to the tools you use to post content.

How it works

Basic flow with a User signing in to a (web)App

  1. The User fills in his/her personal URL This is called Web sign-in.
  2. The App fetches the URL, looking for an Authorization Endpoint. For this, the user can use IndieAuth.com, but it can also be at their own domain. The App redirects the User to their AuthEndpoint.
  3. The User authenticates at their own Authorization Endpoint. IndieAuth.com uses RelMeAuth to authorize users, but if a user uses an Authentication Endpoint on his/her own site, it can be a password, e-mail link, or any other authentication the AuthEndpoint provides. They prove their identity to their AuthEndpoint, the App waits.
  4. The User gets a code from the AuthEndpoint, in the form of a redirect to the App. (With this, the User gives the code to the App.)
  5. The App checks the code with the AuthEndpoint, and if the code is valid and if the User’s identifier matches the identifier the AuthEndpoint gives, the login is completed, and the User can enter and use the app.

How to

Set up using IndieAuth.com

  • Add a link on your home page to your various social profiles with the attribute rel="me"
  • Ensure your profiles link back to your home page
  • Enter your domain in a "Web Sign-In" box to begin using your own domain as your online identity!

See: full setup instructions

Use IndieAuth.com for your OpenID

See indieauth.com#OpenID

Users

IndieWeb Examples

Every person/site in irc-people and Special:RecentChanges has setup IndieAuth on their personal domain, since it is required to edit the wiki!

Micropub

Many Micropub implementations use IndieAuth for authentication, including:

Supporting Sites

(This section is a stub and needs expansion!)

There are a growing number of web sites that you can log into using IndieAuth and gain additional functionality:

Details

  • IndieAuth.com is an implementation of Web sign-in/RelMeAuth with an HTTP API
  • IndieAuth.com is the primary authorization server implementation used by most people currently
  • indiecert implements authentication with client certificates for https explicitly specified when entering one's web address, and only with manually setting state parameter from querystring to arbitrary value after getting "400 Bad Request", when using indieauth login.
  • commentpara.de allows login to IndieAuth enabled sites anonymously
  • Acquiescence is a simple IndieAuth authorization and token endpoint. It is currently limited to GitHub for authorization. Barry Frost uses Acquiescence on his website.

Table of Contents

Contents

The IndieAuth.com Service

The IndieAuth.com service lets you support RelMeAuth logins without writing all the OAuth code for each provider! It also supports a few additional non-OAuth providers such as Email and GPG.

Read the full documentation

Source Code

The IndieAuth.com source code is available on GitHub. Feel free to fork it and submit pull requests if you make any changes!

Issues

This section is about issues with IndieAuth-the-building block, not IndieAuth.com-the-service. Please open specific bugs and action items for the latter on the IndieAuth.com Github project. Issues below should be specifically about IndieAuth as a protocol.

Security

  • The token can be sent to IndieAuth without TLS (or the docs make it appear so); such a request should be refused (*not* redirected) to prevent DNS poisoning, MITM, and race-condition attacks.

Need Simple Copy Paste How To

The explanation in http://waterpigs.co.uk/articles/indiewebcamp-signin-ux/ provides a list of three lengthy descriptions of what you need to setup IndieAuth, which was then subsequently criticized as "this is not a straightforward process" in the post: http://aralbalkan.com/notes/on-evolving-indieauth/

Thus we need a a simple copy paste how to that is not three lengthy descriptions.

Any explanation of how to use IndieAuth needs to start with a 1-2 sentence summary. No more.

Compare with:

Explanations for IndieAuth need to be at least as simple to understand as those for Twitter Sign-in and Facebook Connect.

IndieAuth using form-encoded responses instead of JSON

IndieAuth uses standard form-encoding for requests and response because it has been a standard encoding format since the beginning of the web. If it were a JSON response, then 7 years down the road you'd be asking "why is the response in JSON instead of ____" where ____ is the next trendy thing that replaces JSON. (Remember when XML was the new hotness?)

Proposal for content negotiation: https://www.tuxed.net/fkooman/blog/proposed_changes_to_indieauth_protocol.html#content_negotiation — Wwelves.org perpetual-tripper 02:26, 5 March 2015 (PST)

  • To me this would violate Postel's law, requiring every implementation to publish many different formats. I don't care which format IndieAuth produces, but I do think we should settle on one canonical format. Kylewm.com 10:03, 5 March 2015 (PST)
  • Agreed that there should be only one format. The only valid argument for JSON is that the OAuth 2.0 spec defines the response as JSON. Aaron Parecki 10:06, 5 March 2015 (PST)
  • OK I withdraw my objection to content negotiation. Agree it is a relatively small burden on a relatively small number of providers; it's worth supporting multiple formats for convenience to the large number of consumers Kylewm.com 12:06, 5 March 2015 (PST)
  • Just to be anti-inventing-new-formats (too many of them around and demanding attention), I'd go for form-encoded -- Kartik Prabhu 00:21 2015-03-06
  • I just never saw HTTP POST form encoded _responses_ anywhere, only POST url encoded form requests... Any link to other (REST) services that use this? e.g. XMLHttpRequest does not support form encoded responses at all... fkooman

Requesting additional user details

The auth consumers may want to receive additional information about a user, and not just their homepage URL. Andy Baio raised some points in regard to this in a backer-only Kickstarter post, Opening the Source and The Great Auth Debate, 2015-03-16, when deciding what authenticator to use for Upcoming.org.

  • Silos may give the application access to the user’s social graph: who their friends are, who they are following.
    • This would require some IndieWeb format for following.
    • This is great for applications like readers to start a user off.
  • Silos may give the application location information about the user.
    • This is great for applications like Upcoming.org that want to show relevant events.
    • May be possible by parsing the homepage URL of the user for h-card or recent checkins.

naming confusion

There has been ongoing confusion between IndieAuth(-the-protocol), IndieAuth.com and RelMeAuth.

Most people use IndieAuth by using IndieAuth.com as their authorization_endpoint, which then does RelMeAuth to authenticate them, which has people conflate IndieAuth with rel=me-links.

Some might also just have rel=me links set up and only log in to sites which use IndieAuth.com (or other services that support RelMeAuth directly) to handle login for them, which means they are using RelMeAuth, but not IndieAuth(-the-protocol), while thinking they are using IndieAuth.

  • One problem with the indieauth.com site being called just "indieauth.com" is that people then think that IndieAuth is somehow centralized around this service.
  • In in-person conversations about IndieAuth/RelMeAuth/OAuth with people, I've found that most people think of RelMeAuth when they are talking about IndieAuth. Aaron Parecki
    • Another possibility is to rename the IndieAuth protocol (which is an extension of OAuth 2.0) to make it clear that the OAuth 2.0 extension has nothing to do with RelMeAuth
      • Martijn van der Ven: I think renaming the protocol is your call, Aaron Parecki as the author of said protocol, but I feel it would be unnecessary. Especially if indieauth.com is getting renamed. This feels like an education issue, possibly a documentation issue (which we are already solving with wiki-gardening!). We don’t go and rename microformats because people have been writing blog posts where they used the word “microformats” and then described some other system like Microdata. Instead we educate on what the name microformats is.
        • sknebel: +1, I think that'd lead to even more confusion
    • Martijn van der Ven: Note that no implementers have made the mistake. Acquiescence, commentpara.de, Known, selfauth all talk about IndieAuth as the protocol.
      • Aaron Parecki: This is a great point, and convinces me the name of the spec is fine.

    • Martijn van der Ven: And no consumers advertise it wrong as far as I can find. Are there any implementations that use only indieauth.com and claim to be IndieAuth? That means not using something like indieauth/client and using the service as a fallback, but really using only the service?

      This wiki is an example of that, but also does not claim to use IndieAuth in any way! It describes its login as web sign-in and not IndieAuth. It mentions IndieAuth as an alternative for people who do not want to use their social media accounts, that’s a very correct description:

      indieweblogin.png

      • sknebel Indeed, web-sign in seems like a fitting term here (given that the definitions talk about the general concept of using your homepage URL to sign in, and reference both RelMeAuth and IndieAuth as implementations)
    • sknebel I've been explaining IndieAuth at HWC Berlin to people from "has written an endpoint following authorization-endpoint" over "has logged into the wiki" to "IndieAuth, never heard of it". One of the first category wasn't quite clear on the status of non-Indieauth.com implementations of sites to log-in to (since they'd only used it with sites using Indieauth.com, primarily the wiki), second wasn't necessarily aware of a difference between service and protocol. Explaining the difference (and how RelMeAuth fits in) wasn't an issue, but had to be explicitly mentioned. I believe a different name for IndieAuth.com would go a long way there.
  • The wiki pages for IndieAuth don't always make this distinction clear, work has begun during IndieWebWeek (2017-05) to improve this
    • Work continued 2017-07-19 by moving FAQ and Issue items from this page to the pages they were about: RelMeAuth or indieauth.com.
    • New copy for this wiki page was written in a separate sandbox page where the focus was on explaining IndieAuth and its 3 parts. See User:Vanderven.se martijn/IndieAuth.
      • sknebel +1, to me this is just clarifying and extending existing documentation (e.g. the different endpoints, that currently only have their separate pages, and clearly separating .com from the protocol)

how to should include endpoint definition

This would make sure first time users do not have to try and figure this out themselves. Example:

Getting myself validated through IndieAuth was already taken care of by the rel="me" links, but some services needed me to declare IndieAuth as my authorization endpoint; […]

Here “IndieAuth” refers to indieauth.com-the-service. The discussion above is about clearing up the name issue, this is only about including the endpoint declaration in HTML. Daniel ran into services that offered him to login with IndieAuth and required him to declare the authorization endpoint, completely according to how IndieAuth works. (As documented above, most implementers stick to the spec when they talk about IndieAuth.) This is currently completely left out of the how-to and new users are left to figure it out for themselves.

The wiki leaves users hanging who try to login using IndieAuth outside of the wiki. This how-to issue is documented here specifically because Tantek Çelik wondered why an extra step was needed.

  • I say this is a mistake in the How-to that needs to be addressed. — Martijn van der Ven
  • agreed, instructions about IndieAuth should explicitly include the endpoint —sknebel

To do

Talks and Demos

See Also

Retrieved from "https://indieweb.org/IndieAuth"
Personal tools
Namespaces
Variants
Actions
Recent & Upcoming
Resources
Toolbox