We will be talking about 'The Many Flavors of OAuth' at @APIdaysGlobal San Francisco about #oauth2 and briefly covering identity layers #openidconnect #oidc and #IndieAuth. We have a few tickets to giveaway. Please register with code 'Soonhin' at https://www.apidays.co/sanfrancisco. See you!
#indieauth
-
Will be talking about 'The Many Flavors of OAuth' at https://www.apidays.co/sanfrancisco including brief overview of identity layers #openidconnect #oidc, and #IndieAuth. Use code 'Soonhin' to get free tix. @aaronpk thanks for https://aaronparecki.com/2018/07/07/7/oauth-for-the-open-web.
-
Pretty great to see a new self-hosted IndieAuth server! Congrats @nilshauk, and great project name! https://twitter.com/nilshauk/status/1017485223716630528
-
By golly, it's working. Here's me using Cellar Door to login to #IndieWeb's #IndieAuth page to add my implementation to the list of available implementations. ☺️ https://indieweb.org/IndieAuth#Implementations
-
I just implemented an IndieAuth server for Aperture, which sounds crazy but it's actually pretty cool. Now you can log in to apps like https://indiepaper.io and they can post content directly into a private channel!
If you have an Aperture account, try logging in to Quill using https://aperture.p3k.io as your URL. Here's a little demo of it in action! -
OAuth for the Open Web
OAuth has become the de facto standard for authorization and authentication on the web. Nearly every company with an API used by third party developers has implemented OAuth to enable people to build apps on top of it.
While OAuth is a great framework for this, the way it has ended up being used is much more centralized and closed than prior efforts like OpenID 1. Every service that spins up an OAuth-enabled API ends up being its own isolated system. For example, if I want to build an app that can read someone's step count from FitBit, I have to first go register as a developer on FitBit's website in order to get API keys to use with their OAuth API.
This works okay for major services like Google, Twitter, Facebook, and even FitBit, but breaks down when you start to consider use cases like having someone's personal WordPress blog be its own OAuth server. If I want to build an app that lets you upload photos to your WordPress site, I'm obviously not going to be able to register for API keys on everyone's own WordPress installations. Enabling third party clients to be built against systems like WordPress or Mastodon opens up a huge possibility for some really interesting things. The trick is always how do these apps authenticate the user or obtain a token they can use to access those APIs.
This post details a few specific challenges with OAuth preventing it from being used by independent websites, as well as the solutions to each.
Client Registration
The first major hurdle to overcome is the need for the developer to register to get API keys for the service. In a world where everyone's own website is its own OAuth server, it's obviously not practical to have an app developer register API keys at each.
In OAuth, client registration gives us a few specific things:
-
Provides a unique ID that is used to identify the app throughout the OAuth process, called the client ID
- Provides a place to enter the name and icon for the app which is displayed during login
- Registers one or more redirect URLs for security
- For "confidential clients" (web server apps), registration also provides the client with a client secret
Note that in traditional OAuth, client secrets are not used by mobile apps or JavaScript apps, and OAuth servers will often not even issue secrets to those types of apps. Since we're trying to avoid registration entirely, we can also just avoid using client secrets at all, and leverage the same protections OAuth already has in place for clients that can't use a secret.
In order to avoid registration, we need a solution for the first three bullet points above.
Client ID: Every application needs a unique identifier. If we're talking about turning every website into an OAuth provider, we need a way to have globally unique identifiers for every OAuth app. It turns out we already have a mechanism for this: URLs! In this Open Web version of OAuth, client IDs can be the application's URL. For web-based apps, this is straightforward, as it's simply the website the app is running on. For native apps, this can be the application's "about" page.
Application name and icon: Since the application's client ID is a URL, we can assume every application has a web page that talks about it, and treat that web page as the place the client defines its own metadata like name and icon. A simple way to accomplish this is with Microformats, so that the application's web page just needs to add a couple classes around the name and icon of the app. This is currently documented and implemented as the h-app microformat.
Redirect URL registration: This one is a bit more subtle. The purpose of redirect URL registration is to prevent an attacker from tricking an authorization server into sending authorization codes to the attacker. This becomes especially important when we aren't using client secrets. The trick is that since client IDs are already URLs, we can shortcut the normal registration process by declaring a rule that redirect URLs have to be on the same domain as the client ID. This way, we can avoid a situation where an application claiming to be good.example.com sets a redirect URL to attacker.example.org and steals the authorization code. The only way to get the authorization code to attacker.example.org would be to set the client ID to that domain as well, which a user would hopefully notice.
User Accounts
There are two different situations to consider with regards to user accounts: authentication and authorization. Authentication is the process of proving the identity of the person signing in. Authorization is how an application obtains permission to do something to someone's account.
When we talk about authentication, we are talking about wanting to allow an unknown user to identify themselves to the site they're logging in to. Common examples of this are using your email address as your identity to sign in to a website. You bring an existing identity (your email address) and then authenticate (usually by clicking a link that was sent to your email). The original version of OpenID was created to solve this problem on the web. People identified themselves with a URL, which they were able to prove they controlled using OpenID. This allows a new user to log in to a site without needing a prior relationship with the site.
When we talk about authorization, the situation is subtly different. In this case, we're talking about a user of a website wanting to give permission to a third-party app to access some part of their account. We're very used to this pattern now, which is the typical OAuth use case of granting an application the ability to access your Google Calendar, or logging in to a third party Twitter app.
Authorization: There isn't really a challenge unique OAuth on the Open Web with regards to authorization. Once the client registration problem is solved, everything else falls into place nicely. It is assumed that users are authorizing an application to access an account they already have, so the application will just end up with an access token that works with their existing account.
Authentication: Where we need to define some new behavior is talking about authentication. In this case, we want users to be able to bring an existing identity and use it to log in to other places. This means we need a way to uniquely identify users across the entire web. We can again use URLs as the solution! Every user is identified by a URL. This can be a short URL like someone's domain name, e.g. https://aaronparecki.com/, or for a site with multiple users, can be a URL that contains a path specifying a particular user on the site, e.g. https://github.com/aaronpk.
Discovery
With traditional OAuth services, discovery is not needed since the application author knows which OAuth server they're talking to before they start building the app. There is typically a "Sign in with ____" button in the application that begins the authorization process. In the case of using OAuth for authentication, the common pattern is to include buttons for several common "social login" providers such as Facebook, Google, Twitter and LinkedIn. Before the "social login" space essentially consolidated to these four, there were sometimes a dozen of these buttons on an application's login page, which eventually became known as the "NASCAR problem".
In a world where every WordPress or Gitlab site is its own OAuth provider, there obviously can't be a button for each on a login screen. Instead, we need to find out from the user which server to use to authenticate them.
Since we previously stated that every user identifier is a URL, we can ask the user to enter their URL in the sign-in screen, and then fetch that URL and discover their authorization server from there.
Once we've found the user's authorization endpoint, we can start a normal OAuth request and send them to their server to authenticate. When the server redirects back to the application, it will go and verify the authorization code with their authorization endpoint just like normally happens with OAuth.
Knowing Who Logged In
While knowing any user identity information is technically not part of OAuth, we do need the server to return a user identifier when using OAuth for authentication. In practice, most applications also want at least a unique user identifier in the authorization case as well.
We've previously said that user identifiers are URLs, which solves the global user identity problem, and gives us a mechanism to discover the user's OAuth server. So all we need is a way to return this information to the application after the user has authenticated.
OAuth gives us an easy opportunity to return this to the application: in the access token response when the application sends the authorization code to obtain an access token. The server can at that point return the full user identifier of the user that logged in. As long as the domain name matches the domain that the user entered at the start, the application can consider it successful. This also gives the authorization server the opportunity to canonicalize the user identifier, correcting "http" to "https", or adding a path component to the user's profile URL.
Let's do this!
By now, hopefully you're thinking "this sounds great, Aaron, someone should write this up as a OAuth extension!" I'm glad you asked!
The IndieAuth spec, an OAuth 2.0 extension Earlier this year, I wrote this all up as an extension to OAuth 2.0, called IndieAuth. IndieAuth encapsulates these small additions needed for OAuth 2.0 to work in the Open Web.
Despite this spec being published in January, it has actually been implemented for several years before that. There are many implementations of this extension on the server side, everything from standalone authorization server projects, to a WordPress plugin, and it's even implemented by a commercial service, Micro.blog. As far as consuming apps, nearly every Micropub app has implemented this for logging users in.
For further details on implementing this extension, there are several guides available depending on whether you're writing a client, a server, or just part of a server.
- Authenticating users with IndieAuth
- Obtaining an access token with IndieAuth
- Creating an Authorization Endpoint
- Creating a Token Endpoint
There are a few existing open source projects you can use to get started if you don't want to write your own!
- selfauth - a standalone authorization server using a simple password login
- IndieAuth for WordPress - a plugin that turns your WordPress install into an OAuth 2.0 server
- IndieAuth for Drupal - a Drupal plugin that provides a built-in OAuth 2.0 server
- Acquiescence - an authorization endpoint written in Ruby that authenticates users via GitHub
For further reading, check out the IndieAuth spec. Feel free to drop in to the IndieWeb chat if you'd like to talk about this, or you can reach me on Twitter or from my website.
-
Provides a unique ID that is used to identify the app throughout the OAuth process, called the client ID
-
00dani
https://github.com/00dani
•
Jun 26
An alternative possibility would be to prescribe the format of IndieAuth access codes, as part of the standard. For instance, we could prefix the usual arbitrary implementation-specific access code blob with the expected
mevalue, making it easy for token endpoints to discover the correct authorization endpoint.code=https://00dani.me/$C5r1cuqJk1fUTGrWX4DPHz44jxpgHFor something like that. Then, of course, pure OAuth 2.0 clients would pass through that extra piece of information with no trouble whatsoever, since it's embedded in an existing standard parameter.It's certainly a messy approach, though, and one might question whether OAuth client compatibility is worth adding this complexity to IndieAuth. Additionally, making a change like this now would introduce potential incompatibility: a token endpoint that knows it can pull information out of the access code might still receive an access code from an authorization endpoint that doesn't embed information in the prescribed format, for instance.
Still, prescribing a format for access codes might not be quite as unreasonable as it seems: after all, client IDs are also treated as opaque in pure OAuth 2.0, whereas in IndieAuth they have a prescribed and meaningful format.
tl;dr The more I think about it, the more I think this parameter enables a use case that isn't really necessary. The
meparameter in the code exchange step specifically allows for a token endpoint to be detached from both the Micropub endpoint and the authorization endpoint.Full details below.
The different use cases that are all supported right now:
Integrated Micropub/Token/Authorization Endpoints
This is the simplest case in terms of architecture, but the most amount of work for a developer. In this case, someone writes all three parts of the system. Since they are part of the same system, the mechanism by which the token endpoint validates authorization codes does not need to be standardized, it's all internal.
Both my website and the Wordpress IndieAuth plugin fall under this case.
Authorization Endpoint Service, Built-In Token and Micropub Endpoints
In this case, someone is building a CMS that includes a Micropub endpoint as well as a token endpoint. However, they want to speed up their development, so they use an authorization endpoint service such as indieauth.com.
The client sends the auth code to the token endpoint, and since the token endpoint is part of the CMS, it already knows the only place it can go to validate the auth code is the authorization endpoint service that it's configured to use. Therefore there is no need for the
meparameter, which normally tells the token endpoint where to go to verify the auth code.Authorization Endpoint and Token Endpoint Service
Specifically this case is where a service provides both an authorization endpoint and token endpoint. This is the quickest path to building a Micropub endpoint, since all you need to do is build out the Micropub endpoint itself, and when any requests come in with a token, the endpoint goes and checks whether the token is valid by testing it against the token endpoint service.
This is a very common case with peoples' individual websites, as it offloads the development and maintenance of the security bits to a service. I provide these as a service at indieauth.com and tokens.indieauth.com.
The interesting thing though is that when a single service provides both, there is also no need for the
meparameter at the code exchange step, since the token endpoint already knows where it needs to verify the authorization code since the code was issued by the same system.Separate Authorization Endpoint and Token Endpoint Services
The only case where the
meis needed is when the authorization endpoint and token endpoint are both used as services and they are separate services. Imagine a standalone token endpoint service: the job of this service is to verify authorization codes and issue access tokens, and later verify access tokens. In this situation, a request comes in with an unknown authorization code and it needs to verify it. Since it was not part of the system that issued the code, it needs to know how to verify it. Right now, this is enabled because this request also includes themeparameter, so the token endpoint goes and looks up the user's authorization endpoint and verifies the code there.The thing I'm realizing though is that this is really quite an edge case, and one that I don't think is actually very important. Typically someone who is building a Micropub endpoint themselves will first start by using an authorization/token endpoint service, and there is no benefit to them if those are two separate services. In fact it's probably easier if they are just part of the same system since it's less moving parts to think about at this stage.
Later, that person can decide they want to take over issuing tokens, but still don't want to build out the UI of an authorization service. At this point, they fall under the second use case above. They build out a token endpoint into their software, and since they're using the authorization endpoint service they know where to verify authorization codes.
On the other end of the spectrum, you have people who build the whole thing out themselves, like my website and the Wordpress plugin. In these cases the
meis completely irrelevant in the code exchange step.The particular situation that the
meenables is using a separate service for the authorization and token endpoints, and I can't think of a case where that is actually important. -
What we really need is federated authentication, but that doesn't exist yet.
This sounds like a great use case for IndieAuth. w3.org/TR/indieauth
IndieAuth is an OAuth 2.0 extension, which avoids the centralized problems with existing OAuth solutions by using DNS for "registration" of client IDs and user IDs. Every user account is identified by a URL (for Gitea this could be your Gitea user page), and client IDs are also URLs (would be the Gitea instance home page in this case.)
To log in to your Gitea instance, I would enter my own Gitea profile URL. Your instance would then do discovery on my URL to find where to send me to authorize the login on my own OAuth server (my Gitea server), which would then send me back to your Gitea where it would be able to verify the authorization code against my Gitea instance.
I'd be happy to walk through this in more detail if you're interested!
-
Just finished beta support for email and PGP auth on https://indielogin.com! Please give it a try and let me know if you find any bugs! Here are the setup docs: https://indielogin.com/setup
This means it's now feature complete with https://indieauth.com, so I can now start switching over my apps to use it. With any luck I'll be able to switch the https://indieweb.org wiki to it before IndieWeb Summit! -
Dropping Twitter Support on IndieAuth.com
I've made the difficult decision to drop support for Twitter authentication on IndieAuth.com. Some time last week, Twitter rolled out a change to the website which broke how IndieAuth.com verifies that a website and Twitter account belong to the same person.
Since I am already in the process of replacing IndieAuth.com with two new websites (lots of discussion on the wiki), it is not worth the effort to do what it would take to fix this for IndieAuth.com.
What Changed on Twitter.com
In order to verify that you are the person behind the URL you initially type in, IndieAuth.com checks your website to find a link to a Twitter profile, then checks that Twitter profile to see if it links back to your website. If there is a match, then you'll see the green button for Twitter on IndieAuth.com.
Twitter rolled out a change that prevents normal HTTP requests from returning actual HTML on Twitter profiles. I'm assuming this is part of their effort to fight bots, but it's unfortunate this use case got caught up in that mess. If you visit your Twitter profile in a browser and click "view source", you'll see something like this now.
This is a delightful bit of HTML that sets a cookie via Javascript and then reloads the page. Presumably this happens so quickly that normally you won't notice it.
Fetching a profile URL with curl now returns an empty HTTP body.
Even if I go through the hoops to make IndieAuth.com set cookies and refresh the page, there's no guarantee that they won't just change this again next week. I don't like playing these games, so instead I am just shutting off Twitter support in IndieAuth.com.
Replacing IndieAuth.com
The new version that you'll eventually use to sign in to the IndieWeb wiki is called IndieLogin.com. It is currently in beta, and is not available to other developers, but you can try signing in to the test page there right now. This new version gets around this Twitter problem by not even attempting to fetch Twitter profile pages in the first place.
The new login flow works like this:
-
You enter your website on IndieLogin.com
- IndieLogin.com finds your Twitter profile by checking all rel=me links for one matching twitter.com
- IndieLogin.com shows you a button to authenticate with Twitter immediately (rather than first checking that your Twitter profile links back)
- After you authenticate on Twitter and are redirected back to IndieLogin.com, it fetches your Twitter profile from the Twitter API
- If your Twitter profile as reported by the API includes the initial website you started with, then you're authenticated
This avoids the problem because IndieLogin.com never tries to fetch your Twitter profile HTML. Instead, it uses the API directly. This does mean that you can get into a situation where IndieLogin.com may prompt you with a Twitter button that can fail (if you are logged in to a different Twitter account than the one your website links to). However, it also speeds up the initial login prompt since it doesn't have to go check Twitter before showing you the login button first.
Hopefully I'll be able to launch IndieLogin.com soon so that the lack of Twitter support on IndieAuth.com isn't too annoying. In the mean time, you can authenticate via GitHub or email on IndieAuth.com.
-
You enter your website on IndieLogin.com
-
hosting Homebrew Website Club SF tonight @MozSF!
RSVP http://tantek.com/2018/080/e1
Special guest @aaronpk will demo his #IndieWeb reader setup!
https://aaronparecki.com/2018/03/12/17/building-an-indieweb-reader built on #openweb standards #WebSub #Microsub #microformats2 #IndieAuth #MicroPub #Webmention #Webhooks -
IndieAuth-Client-PHP 0.3.1
This release includes two new methods for quickly developing an IndieAuth client.
The library can now handle all the boilerplate work of generating a state parameter, URL canonicalization, and state management between the request and callback.
Developing an IndieAuth client now requires just setting a few configuration variables and deciding how to show error messages in your application. See the code below for an example of using the new features!
index.php
<form action="/login.php" method="post"> <input type="url" name="url"> <input type="submit" value="Log In"> </form>login.php
<?php require('vendor/autoload.php'); if(!isset($_POST['url'])) { die('Missing URL'); } // Start a session for the library to be able to save state between requests. session_start(); // You'll need to set up two pieces of information before you can use the client, // the client ID and and the redirect URL. // The client ID should be the home page of your app. IndieAuth\Client::$clientID = 'https://example.com/client/'; // The redirect URL is where the user will be returned to after they approve the request. IndieAuth\Client::$redirectURL = 'https://example.com/client/redirect.php'; // Pass the user's URL and your requested scope to the client. // If you are writing a Micropub client, you should include at least the "create" scope. // If you are just trying to log the user in, you can omit the second parameter. list($authorizationURL, $error) = IndieAuth\Client::begin($_POST['url']); // or list($authorizationURL, $error) = IndieAuth\Client::begin($_POST['url']); // Check whether the library was able to discover the necessary endpoints if($error) { echo "<p>Error: ".$error['error']."</p>"; echo "<p>".$error['error_description']."</p>"; } else { // Redirect the user to their authorization endpoint header('Location: '.$authorizationURL); }redirect.php
<?php require('vendor/autoload.php'); session_start(); IndieAuth\Client::$clientID = 'https://example.com/client/'; IndieAuth\Client::$redirectURL = 'https://example.com/client/redirect.php'; list($user, $error) = IndieAuth\Client::complete($_GET); if($error) { echo "<p>Error: ".$error['error']."</p>"; echo "<p>".$error['error_description']."</p>"; } else { // Login succeeded! // If you requested a scope, then there will be an access token in the response. // Otherwise there will just be the user's URL. echo "URL: ".$user['me']."<br>"; if(isset($user['access_token'])) { echo "Access Token: ".$user['access_token']."<br>"; echo "Scope: ".$user['scope']."<br>"; } } -
WebSub and IndieAuth Published on w3.org!
Today, we published the last of the two W3C specs I am editing! WebSub was published as a W3C Recommendation, and IndieAuth was published as a Working Group Note.
WebSub
WebSub is a standardized way for publishers to notify subscribers when new content is available. It was formerly known as PubSubHubbub, which was hard to say, so I'm glad we renamed it.
https://www.w3.org/TR/websub/ One of our goals with WebSub was to ensure that existing PubSubHubbub implementations would still be compliant, so there are already lots of implementations in the wild! If you're publishing content online, want to receive realtime updates when feeds are updated, or are building a tool to facilitate either of these, WebSub is a great fit! You can use the tool at websub.rocks while building your implementation to get immediate feedback!
Thanks to everyone who contributed to the spec, and especially my co-editor Julien!
IndieAuth
IndieAuth is an identity layer on top of OAuth 2.0, and used by Micropub clients. Micropub was published as a W3C Recommendation in May of last year. Today, IndieAuth was published as a W3C Working Group Note.
https://www.w3.org/TR/indieauth/ The Social Web Working Group did not set out with the goal to standardize any sort of authentication mechanism, but since almost all of the Micropub implementations already supported the same mechanism, we decided to publish a "Note" to that effect. (The Micropub implementations that don't use IndieAuth use hard-coded tokens as a shortcut.) Notes are quite different from Recommendations in the eyes of the W3C, as described by this sentence: "The publication of a NOTE by the Consortium implies no endorsement of any kind." The goal of publishing this Note was to capture the current state of interoperable implementations.
One of the things I like most about the W3C standardization process is that specs are published after they describe things that are working, rather than published as an aspirational blueprint. We kind of pushed that definition to an extreme with IndieAuth, since there have been live interoperable IndieAuth implementations for several years now. Previously, I had written up several guides for how to implement the various roles in the IndieAuth flow, but never written it down as its own spec. The guides were certainly useful, as was clearly demonstrated by the fact that people were following them to build out various parts of the ecosystem. But there is also a need for a spec to lay things out and remove any ambiguities along the way.
Thanks to everyone who helped iron out the details of the language in the spec! We made a lot of good progress over the last few months!
What's Next?
So with these two specs published today, we've taken quite a lot of the IndieWeb building blocks through the W3C process!
-
Webmention - enables direct site-to-site commenting and other interactions
- Post Type Discovery - once you receive a Webmention, this algorithm helps your site know what to do with the contents
- Micropub - enables apps to create content on a website
-
WebSub - enables real-time subscriptions to web pages and feeds
- IndieAuth - a way to log in to sites with your domain name, and allow Micropub apps to post to your site
- jf2 - a post serialization format used by some Webmention services and other tools
So here's a few specs and tools that I'm working in the immediate future:
IndieAuth test suite - Like webmention.rocks, micropub.rocks and websub.rocks, I plan to make a tool that will help test your IndieAuth implementation. It will do things like throw tricky situations at your client to ensure you're handling the edge cases properly.
Finally finish renaming indieauth.com - I never should have called it that, since it's doing two completely separate things. You can read about the details here.
Microsub - Microsub is currently an early draft spec. The goal of Microsub is to do for reader interfaces what Micropub did for publishing interfaces. A Microsub server provides a standardized API that reader clients can use to show content. This will help make developing IndieWeb readers a lot easier, and also allows you to keep your subscription list in a server that you control rather than letting the reader own the list.
Monocle - Monocle is my Microsub implementation. It subscribes to feeds and presents a them as a Microsub server so that I can use any Microsub client to view everything. There's still a lot of work ahead for me here, but it's my goal to finally stop using IRC as a reader by getting Monocle to the point of being functional enough to cover all my use cases.
As always, you can help me and the rest of the IndieWeb out by adding support for any of these specs on your own website! We are always excited to welcome new people to the IndieWeb chat if you have any questions!
-
Webmention - enables direct site-to-site commenting and other interactions
-
This spec intentionally doesn't specify how users authenticate themselves to their server, it only deals with how third-party clients can authenticate users where their domain name is their identity.
The analogous version of this in RelMeAuth, with Google as an example, is such: as far as the RelMeAuth client is concerned, it sends the user over to Google, and expects Google to handle authenticating the user. This might involve entering their password, optionally followed by a 2fa mechanism like a Yubikey or TOTP code. That is all invisible to the site they're logging in to.
Similarly, IndieAuth clients do not know how users authenticate to their own server, the client just expects to send them off to the authorization endpoint and get back a response later that can be verified.
It is not a good idea for a spec to require any sort of authentication mechanism between the user and their own authorization server, which is something that the OAuth 2.0 spec has also made clear.
Now, the rest of this conversation is essentially continuing the naming debate of indieauth.com vs IndieAuth the spec vs other options we've considered.
I agree with many of @tantek's points, like
... should be it "just works" even if you only setup rel=me
However, that is describing RelMeAuth, not this spec. And as @Zegnat pointed out, even just adding rel=me isn't necessarily going to guarantee that you can sign in to an arbitrary site that supports RelMeAuth, since you need to add a rel=me link to a service that the site you're signing in to supports, which requires that site to register an OAuth application and deal with that service's API.
I'm in the middle of renaming indieauth.com, the goal is that the wiki will redirect users to indielogin.com to authenticate them using the existing mechanisms: RelMeAuth, email, PGP, and IndieAuth. Nowhere in that flow will users see the term "IndieAuth" unless they include a
rel=authorization_endpointlink on their website to an IndieAuth server of their choosing.I definitely agree that signing in to the wiki needs to be as simple as possible. That's the reason I added so many OAuth providers as well as alternate methods to indieauth.com (soon indielogin.com) in the first place. We've even had some people who want to sign in to the wiki but don't have a Twitter or GitHub account and don't want one, which is why I added things like email and PGP authentication options, which were not described by RelMeAuth.
This is all to say that it's not the goal of this spec to include RelMeAuth. This spec is intended to be just the URL-based extension to OAuth 2.0. If "IndieAuth" is not the right name for this spec, that's a different issue.
-
Announcing the IndieAuth Spec!
It's been a long time coming, but I've finally published a proper IndieAuth spec!
IndieAuth has been around for years, and is even referenced by the Micropub spec. But until now, there wasn't a canonical version of the spec all in one place. Previously it existed as a series of how-to guides on the IndieWeb wiki. Arguably it's actually more useful that way, since the whole point of specs is to communicate a consistent way of implementing something. But it did make it awkward to refer to it formally.
So I'm happy to say that there is finally a spec for IndieAuth, at https://indieauth.net/spec/
This document captures the current state of what has been implemented, and incorporates much of the feedback we've gathered over the years. Most of the document is split up into authentication and authorization sections, for when you are trying to just identify users for sign-in in vs when a Micropub client is trying to get an access token to post to the user's site. Formally it's an extension to OAuth 2.0, and makes several decisions that were left un-specified in the OAuth 2.0 core spec.
If you've implemented any part of this spec, or are thinking about it, I'd appreciate any feedback! Feel free to comment on this post, file an issue on GitHub, or drop a note in the IndieWeb chat!
-
William Narmontas
https://www.scalawilliam.com/
•
Jul 8
Number of sign-ins per month since 2012. If that info is not available, then just monthly number of hits on the site until now would suffice
