#FedIAM 0.2

"Release early, release often", they say. Well, I managed one out of two.

I've been continuing to work on my experimental federated sign-on system, FedIAM.

Summary of changes since release 0.1:

• Split it into three modules - user interface, IdP and RP - and start to reduce the dependencies between them
• Support multiple #OIDC clients (not just Kratos)
• PKCE is now mandatory
• Take some steps towards supporting #ATProto OAuth (not yet complete)

Discourse Demo

The main highlight of this release: I have integrated FedIAM with a real application, Discourse.

For a slightly more interesting demo than the last one, feel free to try it out at discourse.mythik.co.uk!

To log in to this forum:

• Hubzilla/Streams and FedCM users don't need to do anything special - just follow the link, and you'll be logged in!
• Mastodon and classic IndieAuth users can log in by clicking the "Log In" button and entering their ID to start the flow.

In this setup, Discourse is configured to use FedIAM as an OpenID Connect login service. It's quite crude - some of Discourse's features won't work in this configuration.

It's only a demo. I reserve the right to shut it down and/or wipe the database at any time. Don't post anything on there if you want to keep it.

Other News

A couple of interesting developments have taken place since the release of FedIAM 0.1 back in August.

Mastodon 4.3 released

Originally FedIAM's support for #Mastodon was very patchy, because it relies on some OAuth2 protocol changes which were only available in nightly builds at the time. The Mastodon team have now released these changes as part of version 4.3, so a sizeable portion of the Mastodon network can now log in via FedIAM!

ATProto OAuth2

#BlueSky have revealed their design for federated login using #[url=https://zotum.net/search?tag=ATProto]ATProto[/url]. This is not supported by FedIAM yet, but I have a basic proof-of-concept implementation of this.

The thing that's interesting about this is its use of Decentralized Identifiers (DIDs). There seems to be a general consensus that DIDs are the future of identity in distributed systems, but to date BlueSky's ATProto login system is the only concrete proposal I've seen that makes use of them. It takes significant work to get from "maybe we could do it like this" to a design which is well-specified enough to implement in an interoperable way; the BlueSky team have put in this effort, and they've done a great job of documenting it, too.

I hope to offer full support for ATProto/BlueSky logins in FedIAM 0.3.