Simon Willison's Weblog: openid

Does Company ‘X’ have an Azure Active Directory Tenant?

2022-10-01T20:15:40+00:00

Does Company ‘X’ have an Azure Active Directory Tenant?

Neat write-up from Shawn Tabrizi about looking up if a company has Active Directory single-sign-on configured (which is based on OpenID) by checking for an OpenID configuration endpoint. I particularly enjoyed this new-to-me trick: Google’s “I’m Feeling Lucky” search button redirects to the first result, which means it can double as an unofficial API endpoint for returning the URL of the first matching search result.

Via Hacker News

Tags: openid, google, microsoft

Implementing IndieAuth for Datasette

2020-11-18T23:22:17+00:00

IndieAuth is a spiritual successor to OpenID, developed and maintained by the IndieWeb community and based on OAuth 2. This weekend I attended IndieWebCamp East Coast and was inspired to try my hand at an implementation. datasette-indieauth is the result, a new plugin which enables IndieAuth logins to a Datasette instance.

Surprisingly this was my first IndieWebCamp - I've been adjacent to that community for over a decade, but I'd never made it to one of their in-person events before. Now that everything's virtual I didn't even have to travel anywhere, so I finally got to break my streak of non-attendance.

Understanding IndieAuth

The key idea behind IndieAuth is to provide federated login based on URLs. Users enter a URL that they own (e.g. simonwillison.net), and the protocol then derives their identity provider, redirects the user there, waits for them to sign in and get redirected back and then uses tokens passed in the redirect to prove the user's ownership of the URL and sign them in.

Here's what that authentication flow looks like, using this demo of the plugin:

IndieAuth works by scanning the linked page for a <link rel="authorization_endpoint" href="https://indieauth.com/auth"> HTML element which indicates a service that should be redirected to in order to authenticate the user.

I'm using IndieAuth.com for my own site's authorization endpoint, an identity provider run by IndieAuth spec author Aaron Parecki. IndieAuth.com implements RelMeAuth.

RelMeAuth is a neat hack where the authentication provider can scan the user's URL for a <link href="https://github.com/simonw" rel="me"> element, confirm that the GitHub profile in question links back to the same page, and then delegate to GitHub authentication for the actual sign-in.

Why implement this for Datasette?

A key goal of Datasette is to reduce the friction involved in publishing data online as much as possible.

The datasette publish command addresses this by providing a single CLI command for publishing a SQLite database to the internet and assigning it a new URL.

datasette publish cloudrun ca-fires.db \
    --service ca-fires \
    --title "Latest fires in California"

This command will create a new Google Cloud Run service, package up the ca-fires.db (created in this talk) along with the Datasette web application, and deploy the resulting site using Google Cloud Run.

It will output a URL that looks like this: https://ca-fires-j7hipcg4aq-uc.a.run.app

Datasette is unauthenticated by default - anyone can view the published data. If you want to add authentication you can do so using a plugin, for example datasette-auth-passwords.

Authentication without passwords is better. The datasette-auth-github plugin implements single-sign-on against the GitHub API, but comes with a slight disadvantage: you need to register and configure your application with GitHub in order to configure things like the redirect URL needed for authentication.

For most applications this isn't a problem, but when you're deploying dozens or potentially hundreds of applications with Datasette - each with initially unpredictable URLs - this can add quite a bit of friction.

The joy of IndieAuth (and OpenID before it) is that there's no centralized authority to register with. You can deploy an application to any URL, install the datasette-indieauth plugin and users can start authenticating with your site.

Even better... IndieAuth means you can grant people permission to access a site without them needing to create an account, provided they have their own domain with IndieAuth setup.

I took advantage of that in the design of datasette-indieauth. Say you want to publish a Datasette that only I can access - you can do that using the restrict_access plugin configuration setting like so:

datasette publish cloudrun simon-only.db \
  --service simon-only \
  --title "For Simon's eye only" \
  --install datasette-indieauth \
  --plugin-secret datasette-indieauth \
    restrict_access https://simonwillison.net/

The resulting Datasette instance will require the user to authenticate in order to view it - and will only allow access to the user who can use IndieAuth to prove that they are the owner of simonwillison.net.

Next steps

There are two sides to the IndieAuth specification: client sites that allow sign-in with IndieAuth, and authorization providers that handle that authentication.

datasette-indieauth currently acts as a client, allowing sign-in with IndieAuth.

I'm considering extending the plugin to act as an authorization provider as well. This is a bit more challenging as authentication providers need to maintain some small aspects of session state, but it would be good for the IndieAuth ecosystem for there to be more providers. The most widely used provider at the moment is the excellent IndieAuth WordPress plugin, which I used while testing my Datasette plugin and really was just a one-click install from the WordPress plugin directory.

datasette-indieauth has 100% test coverage, and I wrote the bulk of the logic in a standalone utils.py module which could potentially be extracted out of the plugin and used to implement IndieAuth in Python against other frameworks. A Django IndieAuth provider is another potential project, which could integrate directly with my Django blog.

Addendum: what about OpenID?

Fom 2006 to 2010 I was a passionate advocate for OpenID. It was clear to me that passwords were an increasingly unpleasant barrier to secure usage of the web, and that some form of federated sign-in was inevitable. I was terrified that Microsoft Passport would take over all authentication on the web!

With hindsight that's not quite what happened: for a while it looked like Facebook would win instead, but today it seems to be a fairly even balance between Facebook, Google, community-specific authentication providers like GitHub and Apple's iPhone-monopoly-enforced Sign in with Apple.

OpenID as an open standard didn't really make it. The specification grew in complicated new directions (Yadis, XRDS, i-names, OpenID Connect, OpenID 2.0) and it never quite overcame the usability hurdle of users having to understand URLs as identifiers.

IndieAuth is a much simpler specification, based on lessons learned from OAuth. I'm still worried about URLs as identifiers, but helping people reclaim their online presence and understand those concepts is core to what the IndieWeb movement is all about.

IndieAuth also has some clever additional tricks up its sleeve. My favourite is that IndieAuth can return an identifier for the user that's different from the one they typed in the box. This means that if a top-level domain with many users supports IndieAuth, each user can learn to just type example.com in (or click a branded button) to start the authentication flow - they'll be signed in as example.com/users/simonw based on who they authenticated as. This feels like an enormous usability improvement to me, and one that could really help avoid users having to remember their own profile URLs.

OpenID was trying to solve authentication for every user of the internet. IndieAuth is less ambitious - if it only takes off with the subset of people who embrace the IndieWeb movement I think that's OK.

The datasette-indieauth project is yet another example of the benefit of having a plugin ecosystem around Datasette: I can add support for technologies like IndieAuth without baking them into Datasette's core, which almost eliminates the risk to the integrity of the larger project of trying out something new.

Tags: openid, projects, datasette

37signals Product Blog: We'll be retiring our support of OpenID on May 1

2011-01-25T16:17:00+00:00

37signals Product Blog: We'll be retiring our support of OpenID on May 1

The support costs far outweighed the benefits to customers, especially now that 37signals have their own single sign in mechanism that works across all of their products.

Tags: 37-signals, openid, recovered

What are some scalable OAuth and OpenID server implementations?

2010-12-05T18:34:00+00:00

My answer to What are some scalable OAuth and OpenID server implementations? on Quora

Any OAuth library should scale horizontally - I can't see how any one library would be a better choice than another.

Tags: apis, oauth, openid, servers, web-development, quora

Vox is closing on September 30, 2010

2010-09-03T08:50:00+00:00

Vox is closing on September 30, 2010

One month seems like very short notice for closing a service of this size, especially since it functions as an OpenID provider so in addition to migrating their content away users may need to sign in to other services and set up an alternative form of authentication. UPDATE: From the comments, Vox accounts that migrate to TypePad will also have their OpenID migrated, and TypePad will continue to serve OpenID requests for old vox.com addresses. Smart solution.

Tags: closing, openid, sixapart, vox, recovered

RasterWeb: Lanyrd

2010-08-31T20:49:00+00:00

RasterWeb: Lanyrd

Pete Prodoehl calls me out on Lanyrd’s integration with the Twitter auth API at the expense of OpenID. I’ve posted a comment with my justification—essentially, tying to Twitter’s ecosystem means I can actually implement the features I’ve been talking about building on top of OpenID for years, with far less engineering effort.

Tags: identity, oauth, openid, pete-prodoehl, twitter, recovered

App Engine at Google I/O 2010

2010-05-20T15:30:00+00:00

App Engine at Google I/O 2010

OpenID and OAuth are now baked in to the AppEngine users API. They’re also demoing two very exciting new features—a mapper API for doing map/reduce style queries against the data store, and a Channel API for building comet applications.

Tags: comet, google, mapreduce, oauth, openid, recovered, google-io, google-app-engine

Stack Overflow Blog: OpenID, One Year Later

2010-04-14T20:46:02+00:00

Stack Overflow Blog: OpenID, One Year Later

Google’s support is a huge deal—61% of Stack Overflow accounts use Google. Google’s implementation of directed identity has caused problems though, since Google provide a different OpenID for each domain making it hard for Stack Overflow, Server Fault and Super User to correlate accounts. Their solution is to require a (verified) e-mail address from Google OpenID users using sreg and use that as a key for the accounts.

Tags: openid, stackoverflow, google, directedidentity, email, sreg, login, registration

RFC5785: Defining Well-Known Uniform Resource Identifiers

2010-04-11T19:32:28+00:00

RFC5785: Defining Well-Known Uniform Resource Identifiers

Sounds like a very good idea to me: defining a common prefix of /.well-known/ for well-known URLs (common metadata like robots.txt) and establishing a registry for all such files. OAuth, OpenID and other decentralised identity systems can all benefit from this.

Via Mark Nottingham

Tags: rfc, urls, wellknownurls, openid, oauth, robots-txt

Yahoo! OpenID: Now with Attribute Exchange!

2009-12-05T17:25:38+00:00

Yahoo! OpenID: Now with Attribute Exchange!

The nice thing about this is that an e-mail address obtained from Yahoo! via attribute exchange has already been verified, so you don’t need to perform the e-mail roundtrip yourself. I expect a lot of OpenID consuming sites will end up with internal whitelists of OpenID providers who they trust to provide verified e-mail addresses, with users of sites not on the whitelist still getting e-mailed a verification link.

Tags: verification, email, openid, yahoo, attributeexchange

OpenID: Now more powerful and easier to use!

2009-09-25T21:08:21+00:00

OpenID: Now more powerful and easier to use!

The OpenID+OAuth hybrid protocol (where a user can sign in with OpenID and grant an application access to their OAuth protected resources such as a contact list at the same time) is now supported by Google, Yahoo! and MySpace—this feels like OpenID finally coming of age.

Tags: openid, oauth, hybrid, google, myspace, yahoo, identity

Evidence of OpenID at Amazon

2009-07-06T01:25:17+00:00

Evidence of OpenID at Amazon

It looks like Amazon are using OpenID for SSO between their different properties—I clicked a link to sign in to AWS and the URL had OpenID query string parameters.

Tags: openid, amazon, sso, aws

Facebook Usernames and OpenID

2009-06-13T17:01:00+00:00

Today's launch of Facebook Usernames provides an obvious and exciting opportunity for Facebook to become an OpenID provider. Facebook have clearly demonstrated their interest in becoming the key online identity for their users, and the new usernames feature is their acknowledgement that URL-based identities are an important component of that, no doubt driven in part by Twitter making usernames trendy again.

It's interesting to consider Facebook's history with regards to OpenID and single sign on in general. When I started publicly advocating for OpenID back in 2007, my primary worry was that someone would solve the SSO problem in a proprietary way, irreparably damaging the decentralised nature of the Web - just as Microsoft had attempted a few years earlier with Passport.

When Facebook Connect was announced a year ago it seemed like my worst fears had become realised. Facebook Connect's user experience was a huge improvement over OpenID - with only one provider, the sign in UI could be reduced to a single button. Their use of a popup window for the sign in flow was inspired - various usability studies have since shown that users are much more likely to complete a SSO flow if they can see the site they are signing in to in a background window.

Thankfully, Facebook seem to understand that the industry isn't willing to accept a single SSO provider, no matter how smooth their implementation. Mark Zuckerberg made reassuring noises about OpenID support at both FOWA 2008 and SxSW 2009, but things really stepped up earlier this year when Facebook joined the OpenID Foundation Board (accompanied by a substantial financial donation). Facebook's board representative, Luke Shepherd, is an excellent addition and brings a refreshingly user-centric approach to OpenID. Luke was previously responsible for much of the work on Facebook Connect and has been advocating OpenID inside Facebook for a long time.

Facebook may not have committed to becoming a provider yet (at least not in public), but their decision to become a consumer first is another interesting data point. They may be trying to avoid the common criticism thrown at companies who provide but don't consume - if they're not willing to eat their own dog food, why should anyone else?

At any rate, their consumer implementation is fascinating. It's live right now, even though there's no OpenID login box anywhere to be seen on the site. Instead, Facebook take advantage of the little known checkid_immediate mode. Once you've associated your OpenID with your Facebook account (using the "Linked Accounts" section of the settings pane) Facebook sets a cookie remembering your OpenID provider, which persists even after you log out of Facebook. When you later visit the Facebook homepage, a checkid_immediate request is silently sent to your provider, logging you in automatically if you are already authenticated there.

While it's great to see innovation with OpenID at such a large scale, I'm not at all convinced that they've got this right. The feature is virtually invisible to users (it took me a bunch of research to figure out how to use it) and not at all intuitive - if I've logged out of Facebook, how come visiting the home page logs me straight back in again? I guess this is why Luke is keen on exploring single sign out with OpenID. It sounds like the current OpenID consumer support is principally intended as a developer preview, and I'm looking forward to seeing how they change it based on ongoing user research.

As OpenID provider implementation is an obvious next step that can't be that far off - I wouldn't be surprised to hear an announcement within a month or two.

HTTP redirect codes

As an aside, I decided to check that Facebook were using the correct 3xx HTTP status code to redirect from my old profile page to my new one. I was horrified to discover that they are using a 200 code, followed by a chunk of JavaScript to implement the redirect! The situation for logged out users is better but still fundamentally flawed: if you enable your public search listing (using an option tucked away on www.facebook.com/privacy/?view=search) and curl -i your old profile URL you get a 302 Found, when the correct status code is clearly a 301 Moved Permanently.

One final note: it almost goes without saying, but one of the best things about OpenID is that you can register a real domain name that you can own, instead of just having another URL on Facebook.

Tags: facebook, fufacebook, http, openid, sso, thefacebookdebacle

Exclusive: The Future of Facebook Usernames

2009-06-11T09:46:15+00:00

Exclusive: The Future of Facebook Usernames

I have to admit I was planning to just let Facebook get on with it, assuming that the OpenID provider part would show up of its own accord—but maybe I should write a thoughtful and persuasive essay about it after all.

Tags: facebook, anil-dash, openid, funny, urls

Sign in with Twitter

2009-04-20T04:10:33+00:00

Sign in with Twitter

Intriguing: Twitter are now an OpenID-style identity provider... using OAuth.

Tags: oauth, twitter, openid

"Recover my account" link on the login page

2009-02-16T22:22:27+00:00

"Recover my account" link on the login page

For the record, collecting and verifying e-mail addresses is a VERY good idea, even (especially?) if you accept OpenID. A verified e-mail address is still absolutely the best way to deal with lost passwords or “my OpenID isn’t working”.

Tags: email, accounts, identity, openid

Plaxo sees 92% success rate with OpenID/OAuth hybrid method

2009-02-11T17:20:55+00:00

Plaxo sees 92% success rate with OpenID/OAuth hybrid method

Really wish I could have been at the OpenID UX Summit hosted by Facebook yesterday—sounds like an awful lot of important problems are being solved.

Tags: facebook, openid, plaxo, comcast, google

Quoting Chris Messina

2009-02-06T00:19:51+00:00

... Facebook will be hosting the second User Experience Summit for OpenID on February 10th. The goal is to convene some of the best designers that leading internet companies can muster, and bring them together to develop a series of guidelines, best practices, iterations, and interfaces for making OpenID not just suck less, but become a great experience

— Chris Messina

Tags: facebook, openid, chris-messina, usability

Want Proof OpenID Can Succeed? Just Scroll Down

2009-01-16T12:16:03+00:00

Want Proof OpenID Can Succeed? Just Scroll Down

“It’s easier for blogs, which don’t need a lot of demographic information about a user, to let people jump in and start participating socially without filling out a registration form.” Aargh. Repeat after me: supporting OpenID does not mean you can’t require additional registration details through a signup form.

Tags: openid, registration, wired

Wetpaint no longer supports OpenID

2009-01-08T14:53:40+00:00

Wetpaint no longer supports OpenID

I missed this, but they turned off their OpenID support in November due to low usage and high maintenance costs.

Tags: openid, wetpaint

Talking about OpenID

2009-01-05T10:46:57+00:00

Talking about OpenID

“So a relying party walks in to a bar...”

Tags: openid, jargon, relyingparty, comic

Getting OpenID Into the Browser

2008-12-03T10:00:24+00:00

Getting OpenID Into the Browser

David Recordon makes the case for online identity management as a key browser feature (I like the “your browser is currently locked” concept), and argues that Gears is in a great position to deliver it.

Tags: gears, david-recordon, identity, browsers, openid

Clearing up inaccuracies about the Google OpenID IDP launch

2008-11-08T23:11:31+00:00

Clearing up inaccuracies about the Google OpenID IDP launch

Google took some undeserved flack when they launched their OpenID provider. For the record, whitelisting providers fits my definition of the “Open” in OpenID perfectly (providers and consumers are free to impose whatever policies they like).

Tags: whitelisting, openid, google

New OpenID Implementations Abound

2008-10-30T17:11:19+00:00

New OpenID Implementations Abound

I’ve missed linking to a bunch of OpenID news recently—in particular, Google Accounts are becoming OpenID identifiers and LiveJournal has quietly ugraded its consumer support to OpenID 2.0.

Tags: openid, google, livejournal, openid2, martin-atkins

Quoting Jorgen Thelin

2008-10-30T17:09:58+00:00

In the final Production release we will be adding the ability to sign in to the Live ID OpenID Provider using any of the credential types that can be used with regular Live ID sign-in's -- including CardSpace, SmartCard, eID, etc.

— Jorgen Thelin

Tags: cardspace, smartcard, eid, windowslive, openid, jorgen-thelin

Windows Live Adds Support For OpenID

2008-10-27T21:34:22+00:00

Windows Live Adds Support For OpenID

I hope they include the option to log in to the provider using CardSpace, to address phishing.

Tags: phishing, cardspace, openid, microsoft, techcrunch, live

Yahoo! Releases OpenID Research

2008-10-14T16:59:12+00:00

Yahoo! Releases OpenID Research

Extremely valuable research, conducted with a group of typical Yahoo! users. OpenIDs usability remains bad, and if we don’t get it right soon something centralised like Facebook Connect will take over and the Web will stop being open.

Tags: facebook, facebookconnect, openid, usability, yahoo, research

Google's Usability Research on Federated Login

2008-09-22T20:56:33+00:00

Google's Usability Research on Federated Login

Fascinating—suggests an approach to federated auth based on the Amazon.com “Yes, I have a password” login flow. Feels convoluted to me but apparently it tests really well against a mainstream audience. The more research shared around this stuff the better.

Tags: google, usability, openid, login, amazon, authentication, federated

Quoting Tim Anderson

2008-08-29T10:01:32+00:00

New authentication schemes such as OpenID, or Microsoft's CardSpace, may help as adoption increases. These systems make it possible to register for one site using credentials verified by another. Instead of having many sites with poor verification procedures, the internet could have a few sites with strong verification procedures, that are then used by others. The advantage for the user is that they no longer have to jump through multiple hoops for each new site they encounter.

— Tim Anderson, in the Guardian

Tags: tim-anderson, guardian, openid, cardspace, security, captchas

OSCON in 37 minutes

2008-07-29T23:59:14+00:00

OSCON in 37 minutes

45 OSCON talks summarised by their presenters in just 37 minutes, compiled by Gregg Pollack. I get to rant about OpenID for a minute at 27:22.

Tags: openid, video, oscon, gregg-pollack