WeChat ID
aaronpk_tv
Tuesday, July 10, 2018
| bicycle |
28 min
|
|
3.7 miles
|
bicycle |
-
-
-
-
In two weeks, I'm hosting a series of OAuth/OpenID Connect workshops in Chicago, Dallas, and San Francisco with @okta! They're free to attend and there's food/drinks afterwards! Sign up here ➡ http://regionalevents.okta.com/developerworkshoproadshow
-
Like the thought of owning my own online identity via a URL endpoint.. This could mean centralized personal control of you data down the line. https://aaronparecki.com/2018/07/07/7/oauth-for-the-open-web
-
coolaj86
https://github.com/coolaj86
•
Jul 10
@jhabdas I wouldn't.
Total tangent, but here goes...
All Authentication Sucks
For years I've been working on a protocol I call OAuth3 (but I'd like to come up with a better name). It's like a peer version of OIDC or a convenient version of IndieAuth.
However, there have been a number of roadblocks and challenges. Having something work peer-to-peer (decentralized) and be convenient, is neigh unto impossible (but it is possible).
The problem with all existing auth solutions is that they're in one of two camps: Proprietary/Centralized (OAuth2 implementations) or complicated for a non-technical user OpenID/IndieAuth.
What Could Succeed
The way I believe that peer authentication will succeed is by providing a solution that primarily executes on the client device (keypair authentication) but, by default, syncs the public keys to a shared server (with a centralized well-known server as the default), and uses a static page (or 3rd party app if on a phone) - no server APIs required to function - in essentially the way a browser plugin (or native Facebook/Google OAuth on phones) works to manage the exchanges.
Ultimately, browsers need to adopt such a protocol, but it most be open and compatible between browsers. The same is true for smart phones. Until then, the centralized server would serve as a "broker" to serve the user's preferences to other client-side apps.
Most importantly, people need to be able to login like they're used to. It must be easier than the current solutions, not more difficult (and how better to make it easier than by removing the most frustrating - and least secure - part of login: passwords).
What it might look like
First Login on a Device
- I click "Login"
- A pop-up to "generic-auth.org" opens up (better branding, but you get the idea)
- The user types in their email address (or domain name)
- The part after the '@' (if email) is checked for a
/.well-known/peer-auth/index.json- on 200 OK, redirect to that with
?subject={email}for the next step and save the user's choice - on 404 continue using generic-auth.org
- on 200 OK, redirect to that with
- I get a push notification on my device (or an email with a "magic link")
- also, generic-auth.org could link to facebook, twitter, google, etc (though a true peer-auth site could not as that would require having a developer account)
- I click the link in email (or the "Allow" option on the push notification) and I'm logged in (or, if using 2FA), I put in a passphrase or totp code
- I accept any grants (email address, photo access, etc) as needed
- I'm now logged in
- The static app on generic-auth.com (or my custom auth site) caches that this site is allowed login
Secondary Login on Device
- Behind the scenes the app loads a hidden iframe or postmessage to generic-auth.org
- The app is either told to use generic-auth.org, or the peer auth the user supplied before
- The app is given a pseudonymous pairwise identifier and short-expiry token without any interaction
- The user is simply "logged in" with 0 interaction
- The app silently renews the token (completely client-side, no server implementation), as needed
- If necessary, a grants dialog appears asking for my email address, photo access, etc
Logout
- When the user clicks "log out" in any web app (or app) that is passed via iframe or postmessage to the client-side and all private keys are deleted.
- This means that client-side tokens cannot be renewed (as they were securely generated with client-side private keys)
- Likewise an iframe or postmessage is opened for each of the list of sites which have been granted a token, causing their short-lived tokens to expire immediatley
- The generic-auth.org server (or the peer auth server) are notified that they may remove "Chrome on Jon's Macbook Pro" (or whatever) and its public keys from the list of authenticated devices.
Security
- No cookies, only tokens
- Client-side token generation
- Short-lived tokens
- Optional (but default) sync of public tokens and of grants per app/site
- Only Facebook has a properly secure login that could feasibly be used on its own as-is
- Twitter, Google, etc do not support PPIDs and are therefore insecure by default and cannot provide any information that could be used for encryption, etc, as all of the ids are shared among all apps/sites
But That's not a PERFECT Solution!
If you're on one side of a chasm and you want to migrate a host of people to the other side, you need a bridge. Something like generic-auth.org (in the hypothetical scenario above) acts as that bridge. The migration would be complete when browsers and phones natively support open-protocol peer-based authentication that doesn't require 3rd party apps to bridge the gap anymore.
Until that time you have the problem of OpenID/IndieAuth if you go for the "Perfect" peer solution - it requires too much knowledge and effort to intentionally use it. My mom is unlikely to create a website and link it to her other accounts with HTML tags.
The truly "perfect" solution then is the solution that people who don't care about technology and who don't understand the risks with their current login and authentication setups will adopt out of convenience, and perhaps a sense of individuality or pride, but certainly not for being the most technically correct solution.
The Catch-22
Peer-to-Peer can either be convenient for end-users or convenient to develop. It simply can't be both.
The saving grace is that if it's implemented in JavaScript and used in native apps through a web view, we only need a single implementation for the client-side and only 3 to 5 APIs for the server side (sync public keys, send email / push notifications, sync pairwise grants) - none of which require knowing anything about security or keypair signing and encryption - just opaque files, simple messages, and plain-old JSON.
You've basically described IndieAuth, but using
.well-knowninstead of a follow-your-nose approach.Email addresses are URLs too. If you assume an
http://scheme for an email address, fetchinghttp://aaron@parecki.com/provides the server withaaronas the username. Try it out:curl -i http://aaron@parecki.com/I made that site send an HTTP redirect to my actual website, so I can log in with my email address anywhere that uses IndieAuth right now.
Supporting two-factor auth, or passwordless auth is entirely up to the IndieAuth server, as it's not part of the federation spec. In fact, I already have passwordless login to my website using a push notification to my phone which works with every IndieAuth client already because the clients don't care how I authenticate to my website, just that I do authenticate.
As for your point about the bridge, anyone can create a generic IndieAuth provider that provides identities to anyone who wants one and doesn't care about owning their identity. They enter
generic.co/user1as their URL when they sign in. It's up to that service to make actually authenticating users as easy as possible, whether that's by emailing a one-time link, setting up a mobile app for push notifications, using a regular password, or whatever. -
coolaj86
https://github.com/coolaj86
•
Jul 10
@aaronpk Perhaps I misunderstood and need to read carefully. Perusing https://indieauth.com/ what I got was "This is a reboot of OpenID that requires you to create a webpage and link to it".
Perhaps that's not at all related to "IndieAuth" that we're talking about here (I didn't read your article yet, but I will now).
Yeah sorry for the confusion. I've started the (very slow) process of shutting down
indieauth.combecause I never should have launched a service with the same name as the spec. That site is not a good representation of the concepts behind IndieAuth.Please do check out the blog post, it does a much better job of explaining the actual goals and motivations of the spec.
-
I may have gone a little overboard with adding dramatic background music to this screencast. https://developer.okta.com/blog/2018/07/09/five-minute-php-app-auth #countdown
-
Matt Lee
https://mat.tl
•
Jul 10
And the end of explaining this to me. I’ll give you a Mattlcoin which is just me promising you dinner and beers in Boston.
How do I get a Mattlcoin? I'm going to be in Boston in a few weeks which sounds like an excellent opportunity to cash it in. -
I'll trade you an OAuth token for a Mattlcoin
-
Portland, Oregon • Tue, July 10, 2018 5:26pmcoworking
-
I looked through the DreamWidth source code to see if I could implement full-history syndication feeds for them, but they don't have things like querying for posts oldest-first, so it's more invasive than I feel like tackling right now.
Also it's in Perl which would be the fifth programming language I'd have worked on this stuff in over the last ~2 weeks, and the third one I've had to (re-)learn, and I'm getting kind of tired of switching languages this fast.
