Follow

oh my god why is federated identity such a tire fire right now

OpenID 1.x was pretty great! But nobody wants to support it anymore, and all of the Python libraries for it are obsolete and, as far as I can tell, incompatible with Python 3.

OAuth wasn't designed for federated identity.

IndieAuth is built on OAuth.

OpenID Connect is built on OAuth and WebFinger.

WebFinger is shit.

How is any of this stuff an improvement over a simple third-party token exchange?

Β· Β· Web Β· 2 Β· 1 Β· 4

Follow up: federated identity is a tire fire and lots of people are working really hard to solve the wrong parts of the equation

Fuck it, I’m going to start with magic email links

Show thread

Wait except magic email links WILL be abused by people who want to make me look like a spammer

So what’s the solution? Seems like implementing my own OpenID 1.0 auth library is the way to go. That’s not a rathole I wanted to go down but the protocol seems simple enough.

Show thread

Although finding an actual protocol spec is difficult since everything tries to push me toward 2.x or connect

Show thread

anyway if you want to see what I have in mind for a (very rough) example of the login page I put a wireframe online at beesbuzz.biz/static/temp/authl and like okay it has "the NASCAR problem" but it's not, like, going to grow intractably large or whatever and it has a lot of room for experimentation.

Show thread

(Obviously this is just a very rough UI mockup and not a functional prototype, I haven't even begun coding Authl and probably won't get to it for a while.)

Show thread

also to clarify some points:

1. I realize that the terminology still isn't universal, I mocked this up in like 10 minutes
2. My use case is letting my friends log in to my blog to see friends-only content
3. I am not interested in building a universal identity service for the whole Internet, I just want to make setting up federated identity less shitty
4. The actual layout would absolutely just be a template of the website and not a thing that would be provided by Authl, and design is iterative

Show thread

5. This is NOT a replacement for OAuth, it's just a means of getting federated identity so that I can grant access to private content
6. I only even mention OAuth on the page because I plan on supporting it *eventually* but even then it'd just be, like, Twitter and Mastodon, and initially I'm only going to bother with OpenID because like all my friends have Dreamwidth and Wordpress accounts

Show thread

oh good, there IS a supported(ish) Python 3 OpenID library now. Which is difficult to find as it's only linked to from a closed GitHub issue about P3K support on the officially-linked-to library that is referenced from another issue that's been sitting untouched for 5 years. Great.

Anyway, github.com/necaris/python3-ope makes my life a lot easier.

Show thread

okay for anyone who has any interest in my current hair-up-my-butt about identity APIs, I have an extremely rough general design at github.com/PlaidWeb/Authl/wiki

Just to reiterate, this is intended as a general-purpose *wrapper* for other auth mechanisms and is not an auth mechanism itself. The real meat would go into the Handlers, which would mostly be proxies for other Python libraries.

Show thread

In particular I have no interest or desire in establishing a new meta-standard for auth, I just want to make it easy for a Python app to auth against existing standards.

Relevant xkcd: xkcd.com/927/

Show thread

@fluffy this is something I'm interested in and would follow.

@astraluma I hope that I can get others to help out with the actual implementation, too. I'm tired of having to do it all.

@fluffy we'll see? I'm currently focused on not-web projects.

@astraluma that's fair

I mean I really dislike having to start Yet Another Auth Project but all of the existing auth projects just don't suit any of my actual needs

dumb idea, possibly unsolicited advice 

@fluffy the comedy option for solving this issue is to set up something like phpSimpleSaml and implement SAML auth in your app, then just have phpSimpleSaml handle the actual OIDC/OAuth/whatever logon

dumb idea, possibly unsolicited advice 

@maffsie yeah I love how many β€œsolutions” just involve adding another layer of indirection and complexity that still doesn’t solve the actual issue of end user support

dumb idea, possibly unsolicited advice 

@fluffy oh no it’s an absolute shitshow and i get really angry in work about federated identities cause we have a lot of services where there might be contractors who need logins to our stuff, people from corporate, etc, and the solution for the most part is to use a central auth service like Auth0, which is supposed to (in principle) connect to everyone’s active directories, but mostly just uses corporate’s ADFS (which communicates using SAML)

dumb idea, possibly unsolicited advice 

@fluffy and most of the applications that consume these federated identities just use SAML to communicate with the IdP. i recently wrote a web service for internal use that used the central auth service - i think it would have been easier to just implement saml rather than using JWTs and stuff because at the end of the day my application doesn’t support SSO when all the saml stuff does.

dumb idea, possibly unsolicited advice 

@maffsie yeah and SAML is great for its intended use case but as far as I understand it, my use case is different enough that it isn't really applicable. And trying to shoehorn it into a SAML context doesn't make the SAML part actually useful for my goal.

dumb idea, possibly unsolicited advice 

@fluffy yeah, it isn’t one size fits all, I was mostly comparing the ease of implementation in a roundabout way. OAuth/OIDC/etc are immensely difficult to actually understand.

Show more

@fluffy I've been griping about the same thing. The W3C had a simple, neat, easy to implement identity system where you would have a URL representing an identity, a certificate FOR that URL, and a signature BY the certificate at (or pointed to by something in the thing at) the URL. (Among other things.)

And now apparently Inrupt is pushing OpenID Connect.

@Azure meanwhile mastodon just uses ActivityPub for everything, conflating identity with subscribing (and also building everything on OAuth + webfinger but in a DIFFERENT WAY than openid Connect, because of course)

Sign in to participate in the conversation
Queer Party!

A silly instance of Mastodon for queer folk and non-queer folk alike. Let's be friends!