Allow Mastodon to be used as an OpenID provider

[Sylvhem]

Nowadays, a lot of website allow their users to log in by using their Facebook, Twitter or Google+ account. User-wise, one of the advantages of doing so is to be allowed to use a lot of different websites using the same password everywhere.
However, using centralized and company owned website like those ones as identity provider is not without any risk.

OpenID is an open standard and decentralized authentication protocol allowing users to log into a website using a third party provider of their choice. It works over OAuth 2.0 and has been finalized three years ago.
It is deployed but not widely used yet, shadowed by the big centralized social networks. My assumption is that the main obstacle to its adoption is that many OpenID implementations don't provide any useful service beside acting as an identity provider unlike Facebook and Twitter.

I suggest we add OpenID support to Mastodon. By doing so, we'll allow anyone with a Mastodon account to log in to any website using this protocol. It'll add to Mastodon a missing feature viewed as essential by some, and could encourage webmasters to implement this feature in a near future.

References:

• OpenID Connect specifications
• RFC 6749

---

• I searched or browsed the repo’s other issues to ensure this is not a duplicate.

[ghost]

On one hand, this would be really cool, on the other hand, it would probably be quite a mess everytime an instance goes down. Interesting nonetheless!

[remmah]

Seconded... having mastodon instances become identity providers can open the door to a variety of complementary web services. Building federated replacements for SoundCloud, YouTube, Twitch, etc. could be much easier if people could use their existing mastodon identities. The email address associated with the account could be used as a backup in the event of the relevant mastodon instance shutting down.

[urchinhead]

I use mulit instances. The registration is required at every instance. It bother me. I'd like to use my account of my main instance. If mastodon has idp and sp function, We can use Single-Sign-On.
Also, If I registered malicious instances, We can revoke that access token easily.

[bunnybooboo]

What about IndieAuth?

[Openmedianetwork]

We need a working #4opens identity to push the #openweb into relevances so this is interesting for me.

[charlycoste]

@bunnybooboo OpenID can do the same as IndieAuth, but can also handle the provider aspect. http://openid.net/specs/openid-authentication-2_0.html#anchor50

[burntout]

It's been suggested that it would be nice for distributed comments on blogs etc..
https://campaign.openworlds.info/@jim/99811760955215781

[fluffy-critter]

OpenID 1.x is pretty much dead in the water but having Mastodon instances provide IndieAuth would be really great, as it would make it a lot easier for people to join in on IndieWeb stuff without having to set up their own website.

[fluffy-critter]

It looks like adding IndieAuth functionality to Mastodon is trivial, since Mastodon already supports OAuth. It just needs a couple of links to be added to the profile page; either the following headers:

Link: <https://$INSTANCE/oauth/authorize>; rel="authorization_endpoint"
Link: <https://$INSTANCE/oauth/token>; rel="token_endpoint"

or the following <link> on the user profile page:

<link rel="authorization_endpoint" href="/oauth/authorize" />
<link rel="token_endpoint" href="/oauth/token" />

In theory, if these two links get added then anyone should be able to authenticate against e.g. https://indielogin.com/ using their Mastodon identity.

[nightpool]

mastodon requires apps to register before it will give out oauth tokens, is there a provision for this in the indieauth api?

…

On Sun, Dec 16, 2018 at 4:08 PM fluffy ***@***.***> wrote: It looks like adding IndieAuth functionality to Mastodon is trivial, since Mastodon already supports OAuth. It just needs a couple of links to be added to the profile page; either the following headers: Link: <https://$INSTANCE/oauth/authorize>; rel="authorization_endpoint" Link: <https://$INSTANCE/oauth/token>; rel="token_endpoint" or the following <link> on the user profile page: <link rel="authorization_endpoint" href="/oauth/authorize" /> <link rel="token_endpoint" href="/oauth/token" /> In theory, if these two links get added then anyone should be able to authenticate against e.g. https://indielogin.com/ using their Mastodon identity. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#4800 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAORV5sTVGsqGKGJXndS_ItvPQNKFDyqks5u5rZfgaJpZM4PLWnB> .

[fluffy-critter]

I don't know enough about IndieAuth or OAuth to answer that question, but my understanding is IndieAuth is based on top of OAuth and would support whatever workflow is necessary for that to work. Honestly a lot about this whole world is confusing and I wish IndieWeb folks would have just stuck with existing, relatively-well-understood protocols like OpenID.

[jalcine]

RE: #4800 (comment); IndieAuth doesn't prohibit one from being a provider cc: @charlycoste.

@fluffy-critter is close on the nose though. The quickest MVP of this would be to have Mastodon expose IndieAuth support as a provider; similar to the grant flow for OAuth 2.0 works.

Regarding @nightpool's note on registering applications; no. Mastodon would have to self-register the site as an application. That would mean the authorization endpoint would have to either be tweaked for IndieAuth requests (of which the only "uniqueness" I can think of would be client_id which should be a URI but doesn't have to be a fully formed one). See Aaron's mention below.

Implementing IndieAuth support would be dramatically simpler than adding OpenID support.

[jfmcbrayer]

This would be a real win for developing loosely tied federated services that could live on another site but just allow people to log in with their existing social account.

[aaronpk]

@nightpool IndieAuth ditches the need for client registration because all clients are identified by their own self-asserted client_id which is a URL. Internally you can register that on the fly if you need an internal ID for the app. You can fetch information about the app from this client_id URL. This is all described in the spec.

[AlexM4H]

Mastodon currently uses doorkeeper. Couldn't doorkeeper-openid_connect (https://github.com/doorkeeper-gem/doorkeeper-openid_connect) also be added to get OpenID Connect functionality? This library implements an OpenID Connect authentication provider on top of the Doorkeeper OAuth 2.0 framework.

[SilverWolf32]

@fluffy-critter

OpenID is pretty much dead in the water...

Do you mean OpenID, or OpenID Connect? Despite the very similar names, they're two different things. (: OpenID Connect seems to be a replacement for the older OpenID; it's actually based on OAuth.

[AlexM4H]

I think he means OpenID Connect...

[fluffy-critter]

Hi, she means OpenID 1.x, which is different than OpenID 2.x or OIDC. OIDC is alive and well, and is what Apple is using for "Sign In with Apple."

OpenID 1.x in particular is great for federated identity but pretty much everyone's dropped support for it except for a handful of legacy services (Livejournal, Dreamwidth, Ubuntu Launchpad, etc.). Which is a shame as it was a great protocol that was perfect for federated identity.

If I'd meant OpenID Connect I'd have said OpenID Connect.

Anyway, @AlexM4H maybe you should consider waiting for me to answer rather than putting words in my mouth. It's not polite.

[SilverWolf32]

Who is "she"? The OP? Because they look like they're talking about OpenID Connect – that's the spec they linked to, and they mentioned it working over OAuth. (:

[aaronpk]

IMO there's not a lot of value in supporting OpenID 1.x anymore, as there are virtually no consumers of it left, especially once StackOverflow dropped it.

It would be far more useful (and also far easier) to make Mastodon an IndieAuth provider, since that's built right on top of OAuth 2.0, but works without pre-registration of clients, so actually makes sense to use in a situation where you have an arbitrary number of apps logging in to an arbitrary number of providers.

[SilverWolf32]

Huh, IndieAuth looks interesting. What is pre-registration of clients? I'm not very familiar with how all this works; do you mean how every site has a button for every provider they support, and you can't (generally) just add your own provider to the mix?

[fluffy-critter]

@SilverWolf32:

Who is "she"?

"She" meaning me. AlexM4H seemed to be referring to my post which you were referencing.

Anyway, here is my understanding about the various protocols:

• OpenID 1.x was an identity-focused federated protocol which doesn't require any pre-existing peering agreements or API keys. It has an identity-based discovery mechanism whereupon you can get the OpenID endpoint by querying a URL. It was very heavily supported for a couple years (and was quite simple to implement) until it fell out of favor for OAuth instead. Recently StackExchange dropped support for it, citing nobody using it anymore. Thus, "dead in the water." It is still supported by a handful of providers but it shouldn't be relied on as a long-term strategy.

• OAuth is an open [EDIT] authentication authorization, rather than identity (aka authentication), protocol. It requires a peering agreement, in the form of application-specific API keys, and all things that use OAuth to identify you also get API access to your account and are registered as an "application" on it. There is no discovery mechanism for it, so you have to say which OAuth provider to use up-front; OAuth being an API access mechanism does not even have any single common subset for the purpose of providing identity or profile information. It is completely unsuitable for self-hosted things.

• Mastodon uses OAuth and provides some sort of mechanism for applications to register themselves as an application and get an API key. So it automates the process of getting a peering agreement, at least.

• OpenID 2.x is based on OAuth, and (as I understand it) requires a peering agreement, in the form of application-specific API keys. I am not sure about whether there is a discovery mechanism or a means for an application to anonymously request an API key without registration.

• OpenID Connect is based on OAuth, and, again, requires a peering agreement, in the form of application-specific API keys. It does not provide a discovery mechanism, so you have to declare which service you want to identify against as a user. This leads to the so-called "NASCAR problem."

• IndieAuth is as @aaronpk stated above and is, to me, the most interesting path forward, as while it's based on OAuth it's also designed specifically to allow federated identity access without requiring a persistent per-application API key or peering agreement between application and service, and also provides a discovery mechanism which is very similar to OpenID 1.x's. This was something I brought up in my original post on this thread.

[SilverWolf32]

(On the first line: Oh, duh. That should have been obvious, sorry.)

Oh, OK! This all makes a lot more sense now, thank you!

I wasn't aware OpenID Connect required providers and apps to set up keys beforehand. That would definitely be a problem, what with the entire nature of Mastodon. (:

[aaronpk]

Huh, IndieAuth looks interesting. What is pre-registration of clients? I'm not very familiar with how all this works; do you mean how every site has a button for every provider they support, and you can't (generally) just add your own provider to the mix?

Even worse. Right now, if you want to go add a "sign in with github" button to your Mastodon instance, you have to go register API keys at GitHub. That's fine when there are a limited number of identity providers: GitHub, Twitter, Facebook, Google, etc.

If someone wanted to go publish an app to the Google Play store which helps users manage GitHub issues, that developer has to go register API keys with Google.

In the Mastodon world, each Mastodon instance is its own identity provider. It is obviously impossible to require that an app developer register API keys with each Mastodon instance.

IndieAuth handles it by having clients identify themselves by a URL. Either the URL that the app instances is running at (e.g. one Masto user logging into another Masto instance), or the app instance using its "home page" as the identifier in the case of native apps.

[decentral1se]

On a related note, #16221 could use some eyes btw folks!

[fluffy-critter]

On a related note, #16221 could use some eyes btw folks!

It's related, but in the opposite direction - the request here is to have the ability to log in to other things using Mastodon as their identity (via OpenID, IndieAuth, etc.)

[fpesari]

I think this could have huge potential for the free (as in freedom) web. It could lift the burden of authentication off web developers and make life easier for web admins as well, who would have to worry less about data theft.

[ctoth]

I was just sitting down to set up a Mastodon server which also provided email and Matrix accounts for each account automatically. I first tried to find if Mastodon supported SSO, which it apparently doesn't. Okay, I thought, let's see if we can go the other way and have it act as an identity provider. This seems to have stalled, though. Is there anything I can do usefully here as a random developer? Does this need someone to architect it out and some organization buy-in and whatnot? Is it dead in the water?

[trwnh]

@ctoth Mastodon should support LDAP, it's just there is not any tutorial on the documentation site currently. I'm not sure how it works as I've never tested it, but there appears to be the following environment variables for it: https://docs.joinmastodon.org/admin/config/#external-authentication

[goatrocks]

As mastodon and selfhosting grows in popularity, this becomes a frequent wish. I'd love to offer more services to friends and family without also having to configure individual logins when we already have a mastodon instance running :). Having mastodon act as an identity provider would be extremely useful!

[onokje]

I would love to put "Sign in with Mastodon" on my websites instead of facebook/twitter/google.

[fluffy-critter]

I would love to put "Sign in with Mastodon" on my websites instead of facebook/twitter/google.

That’s actually already possible to do in a protocol-specific manner; see Authl for an example of a library which supports that.

This issue is more about allowing Mastodon to support extant protocols that aren’t Mastodon-specific, though, specifically OpenID, but there’s also been mention of IndieAuth which has a very similar flow to Mastodon but doesn’t require generating a disposable “client” connection up-front (and has a few other affordances to standardize how profile information is shared).

[kaffeeringe]

I would like to start a regional Mobilizon service. I think adoption will be far better, if people can use their Mastodon account to log into it. Some kind of auth-system among all Fediverse services would be great.
Even something, supported be other software too.
E.g. I could use my own Nextcloud account as logon for Mastdon. That is an identity provider I personally control.

[hex-m]

@kaffeeringe Mobilizon and Nextcloud already support external authentication (SSO). You should be able to setup an IDP (keycloak, authentik,..) and configure all three tools to delegate the login to that IDP.

But of course: Mastodon becoming an IDP would also solve your problem.

[kaffeeringe]

It shouldn't just work for me. 😉

[almereyda]

More creative use cases for delegating authorization (authz) and authentication (authn) to an external identity provider will become available when OpenID Federation receives wider adoption after release:

• OpenID Federation 1.0 - draft 32
• On the journey to an Implementer’s Draft: OpenID Federation draft 31 published – Mike Jones: self-issued

This will come with better support for the OpenID Connect Registration extension, which depends on the OpenID Connect Discovery extension.

• Final: OpenID Connect Dynamic Client Registration 1.0 incorporating errata set 2
• Final: OpenID Connect Discovery 1.0 incorporating errata set 2

This would allow for dynamic client registration for third parties and eventually offer users the choice to login with their identity provider at hands; here: their Mastodon instance.

When sites will offer to login via OpenID Federation, it will allow to decentralise identity provisioning to:

establish trust between an RP and an OP that have no explicit configuration or registration between them in advance

Mastodon instances that activate their OP (OpenID Provider) could then dynamically create client configurations for the intended RPs (OAuth 2.0 Clients using OpenID Connect; websites one visits and where one wants to login with Mastodon), in so that sites offering Mastodon login would not need to know in advance from where authentication attempts will happen, while still allowing for secure and private authentication/authorization.

This maps quite well to the decentral deployment topology of Mastodon instances across the web.

---

Given the course of the discussion, can we update the title here to name OpenID connect specifically, and delegate all OpenID 1.x discussion around rel=me logins to

• Add support for IndieAuth authentication #24066

[ThisIsMissEm]

@almereyda OpenID Federation is still a draft, and the whole chains of trust thing likely poses an implementation issue for the fediverse as there's no central source of trust. There's this ticket open about it: swicg/general#38

Was raised during the joint Solid / SWICG meeting a few months ago.

[dariabloodworth]

Adding a comment because I have an app I want to develop but I don't want to have to create a wholeass separate login thing.

[ThisIsMissEm]

Adding a comment because I have an app I want to develop but I don't want to have to create a wholeass separate login thing.

You could already build that using Mastodon's OAuth 2.0 authentication mechanism, you don't need OpenID for that

[trwnh]

You could already build that using Mastodon's OAuth 2.0 authentication mechanism, you don't need OpenID for that

that's specific to mastodon only, though

[fluffy-critter]

Yes, the point to supporting OpenID/IndieAuth/etc. is so that Mastodon can be used for login without needing any Mastodon-specific support on the part of the thing that needs it.

Implementing a Mastodon-specific OAuth client isn't all that difficult (see Authl for an example of how to do it) but in an ideal world it wouldn't be necessary at all - Mastodon could be providing a common mechanism and be a model for the rest of the Web.

Incidentally, IndieAuth is a tiny extension to OAuth which allows a user identification flow without requiring the creation of a temporary client token, and in principle shouldn't be terribly difficult to add to Mastodon. IndieAuth flow could be implemented such that the scope is limited to read:accounts which is all that should be necessary for this use case.

[ThisIsMissEm]

I am wanting to add support for IndieAuth and FedCM in the future (see: #31151) to Mastodon, however there's a lot of other work necessary.

In general, as a server operator, if you want to provide your users with multiple applications through SSO, Mastodon now supports OIDC, PAM and LDAP single-sign-on. I would strongly discourage making Mastodon your Authorization Server for external apps that do not depend on the Mastodon API (i.e., social sign-in).

However, we have made a small improvement recently which is the introduction of a profile scope (4.3) which allows for accessing only basic information about the currently authenticated user.

Why do I strongly discourage using Mastodon as your primary Authorization Server?

• because Mastodon only implements parts of OAuth 2.0
• because Mastodon is not designed to be an Authorization Server, it just happens to be one because it needs to provide access tokens for it's API for clients. This means it's perhaps not as security hardened as an actual dedicated OIDC / OAuth server.
• Mastodon's implementation of OAuth 2.0 does not use JWTs, uses non-expiring tokens, and does not support refresh tokens (support is planned for each to varying degrees)
• Mastodon does not implement OAuth 2.0 Dynamic Client Registration (see: OAuth 2.0 Dynamic Client Registration Compatibility #30154 )
• There are various other security implications which I cannot go into right now.
• Additionally, should you later decide that you don't want a Mastodon server but instead a server, then you're basically screwed with the migration & loose the user accounts without a custom data migration script; Using an external identity provider limits that impact to just loosing content.
• Mastodon does not provide a mechanism for limiting which users can uses which OAuth Applications (e.g., if you used Mastodon as your AS with Pixelfed and Lemmy (SSO support landing soon) then you couldn't say "only Y users get access to Pixelfed and Z to Lemmy", it'd be all-or-nothing.

Finally, Mastodon does not implement OpenID as provider, and probably never will, since it currently implements only parts of OAuth 2.0 and the gap between those, and the potential incompatiblities is HUGE.

[ThisIsMissEm]

@fluffy-critter

without requiring the creation of a temporary client token, and in principle shouldn't be terribly difficult to add to Mastodon

It's actually a lot more complicated than you might think. @aaronpk and I have actually started writing a IETF I-D after a call discussing "how Mastodon could support FedCM and IndieAuth in the future". There is an issue to implement that I-D here: #31151

Basically the problem comes down to "how can you get a client" because even in IndieAuth you still need one, you just don't see it. IndieAuth now references OAuth Client ID Metadata Documents: https://indieauth.spec.indieweb.org/#client-information-discovery-p-2

[fluffy-critter]

Basically the problem comes down to "how can you get a client" because even in IndieAuth you still need one, you just don't see it. IndieAuth now references OAuth Client ID Metadata Documents: https://indieauth.spec.indieweb.org/#client-information-discovery-p-2

I haven't kept up on the latest developments in the IndieAuth protocol, as I've been taking a much-needed break from working on this stuff. My last comment on this thread was based on having implemented relevant features in my own software quite some time ago, and it's a bit disheartening to hear that IndieAuth has made sweeping protocol changes that may complicate matters for implementation.

My own purposes for supporting Mastodon (and IndieAuth for that matter) as a sign-in flow is for simple, low-stakes identity management for things where it's useful to know who's doing things, not for high-stakes applications requiring airtight security. My personal use case is simply for providing a modicum of access control to private blog posts, which doesn't need any app-specific behavior (and currently the vast majority of people who access my blog in that way just use emailed magic links, which is a far worse security situation than the things you describe as being problematic for Mastodon).

[aaronpk]

it's a bit disheartening to hear that IndieAuth has made sweeping protocol changes that may complicate matters for implementation

See Issue 133 for the discussion of adding this new metadata discovery to IndieAuth, I would hardly call this "sweeping protocol changes". There are many links in the issue that show a single commit that changes the metadata discovery. And in some cases, clients didn't have any metadata using the old method anyway, so it was only a bit of net new code. This is also effectively backwards compatible, since metadata discovery might fail and the AS has to decide how to proceed under those conditions, so for any clients that have dropped support for the previous method that would just be considered a failure to fetch the metadata under the old method.

[y3t1sec]

Hi everyone,

It looks like I'm a bit late to the discussion, but I wanted to jump in. A friend recently asked about enabling IndieAuth on our private Mastodon instance, which led me to research the topic for a few hours—eventually bringing me to this thread.

I've learned a lot from the incredible and talented folks who have contributed here, and I've also conducted some additional research. As a novice with the underlying technologies used by both Mastodon and IndiePub, I wanted to verify if my understanding is correct: Can I integrate IndieAuth into Mastodon using the following project?

reiterate-app/authorio

Since this hasn’t been mentioned in previous posts, I wanted to confirm before spinning up a test instance and trying it myself.

[fluffy-critter]

I'm not familiar with that project but at least if the README is to be believed then it should be capable of providing an IndieAuth server, yeah.