Mastodon: 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

---

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

[Komic]

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 [e-mail] 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 on the user profile page:

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
https://github.com/tootsuite/mastodon/issues/4800#issuecomment-447676050,
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: https://github.com/tootsuite/mastodon/issues/4800#issuecomment-376543478; 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.

[AlexM4H]

I'm interested to add to my website (a crowdfunding site for open source projects) 'sign in with mastodon' to give mastodon and our community a greater audience. Mastodon is a great social network which supports ActivityPub to connect to the Fediverse.

[johnss]

i dont think it is a good idea, an OpenID server should have a well established long running services that unlikely will down in the near term, because Mastodon have no ads, instance come and go some can survive up to several years and some just few months or weeks, if the instance is lost all the OpenID account connected to that account also lost.

Even if the service can sustain long time, if banned account can not use OpenID it can make login impossible to other connected account, my twitter get banned in the past and cannot login to other site using twitter OAuth, fortunately twitter now allow OAuth for banned user

Yes mastodon can allow using OpenID for banned user but there is no solution for dead instance.

[fluffy-critter]

i dont think it is a good idea, an OpenID server should have a well established long running services that unlikely will down in the near term, because Mastodon have no ads, instance come and go some can survive up to several years and some just few months or weeks, if the instance is lost all the OpenID account connected to that account also lost.

Even if the service can sustain long time, if banned account can not use OpenID it can make login impossible to other connected account, my twitter get banned in the past and cannot login to other site using twitter OAuth, fortunately twitter now allow OAuth for banned user

Yes mastodon can allow using OpenID for banned user but there is no solution for dead instance.

The point to OpenID or IndieAuth or whatever in this case is to act as an identity proxy, not necessarily to act as credentials for signing into another site. Identities like these are fairly disposable and it's totally expected that people might have more than one of them or want to migrate between them.

My big use case for it is granting friends-only access to entries on my blog, for example. I fully expect some friends to authenticate in multiple ways, and for them to change their identities as time goes on. Or for them to forget which particular Mastodon ID they used to sign in to begin with.

I do agree that Mastodon IDs are far from durable, but there are plenty of non-durable contexts where an OpenID/IndieAuth/etc. (authentication, rather than authorization) flow is very useful.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[trwnh]

would still be interesting to do

[fluffy-critter]

Yeah. For my own purposes I ended up writing a thing called Authl which wraps a bunch of different auth mechanisms, including Mastodon, and so far that's been incredibly popular as a login method on my website. As such I feel it would be incredibly useful for Mastodon to be able to provide OpenID (1.x) or IndieAuth authentication natively; the latter in particular would be great since then people could use many IndieWeb services without needing to set up their own website, which is the biggest barrier to entry.

[fluffy-critter]

There's some pretty enormous selection bias here, but on recent private blog posts, I've had 17 authenticated viewers, of which 6 authenticated via email, 4 via Twitter, and 7 via Mastodon. So at least as far as federated identity brokerage for blog authentication goes, Mastodon is pretty popular.

(I also had 4 attempted viewings from unknown random folks who authenticated via email but they look like spammers and can probably be ignored.)

On my most recent post the stats are even more Mastodon-heavy: 4 by email, 1 by Twitter, and 5 by Mastodon.

As far as supporting IndieAuth goes, having implemented the client side of IndieAuth as well as a couple of OAuth providers (namely Mastodon and Twitter), it seems like adding IndieAuth to Mastodon's existing OAuth flow would be incredibly straightforward.

[tailot]

@fluffy-critter Have you evaluated magic link ?

• https://hackernoon.com/magic-links-d680d410f8f7
• https://reallifeprogramming.com/how-to-implement-magic-link-authentication-using-jwt-in-node-8193196bcd78

The combination of magic links and private messages is perhaps the easiest solution ;-)

[fluffy-critter]

I actually do support magic links, among other mechanisms in my blog. That's not particularly relevant to the point of this request.

[johnss]

the only reliable and stable auth system is decentralized auth system using blockchain or other DLT, you may already know, using blockchain all user account is replicated in multiple server so it is practically impossible to be taken down, the auth server will always up and running

[fluffy-critter]

nah

[unmellow]

this should also be optional on an instance by instance basis for security-minded people

[unmellow]

@johnss I think something like that should be its own platform entirely

[fluffy-critter]

@unmellow I don't see why it should be mandatory, but what's the security risk to the instance if it's being used to provide identity? This wouldn't provide external clients the ability to read/write posts on the Mastodon server itself, nor would it allow people to log in. Mastodon's existing security model would be preserved, this would just allow for more things to make use of Mastodon instances as identity provider to those other things.

[unmellow]

I just had a brain fart and forgot how these work

but if I were to login to mega drive with an auth wouldn't there be a risk of someone manipulating the authenticator to get into my drive? or is there some way to make sure that can never happen

edit: that wouldn't be a problem for mastodon to solve I now realize but for the sake of argument can we pretend I said logging into one instance with another

[fluffy-critter]

Yeah but that wouldn't be dependent on Mastodon, that'd be on the client (in this case Mega Drive) to implement identity validation correctly.

That said, there is currently a deficiency in the IndieAuth spec regarding multi-user domains; see https://github.com/indieweb/indieauth/issues/35 for a proposed amendment to the specification. However, that wouldn't be an issue with Mastodon since there's no way for a user to provide an arbitrary validation endpoint, and it's again on the consumer/client to worry about. (The primary attack surface is on shared-domain webhosting sites like tilde.club or whatever.)

I also don't see there being any reason to use this for cross-instance login; this isn't for allowing one person to log in to one Mastodon instance with an OpenID/IndieAuth/etc. identity, just for allowing Mastodon to be used as a provider for those protocols for other websites (e.g. IndieWeb things and random web apps that like to use federated identity rather than managing their own login mechanisms). You can't have a password breach if you don't store passwords to begin with.

As mentioned above I have Mastodon-specific federated login support in my identity layer on my website, which just registers as a read-only client long enough to validate identity and then immediately discards that registration, and that works for my needs, but I'd love to see a future where people don't have to support a bunch of piecemeal protocols to allow for federated identity, and I think Mastodon could be a huge part in driving adoption of OpenID 1.x and/or IndieAuth. (My preference at this point would be IndieAuth, which would also be theoretically easier for Mastodon to add since it's an extension to OAuth 2 which Mastodon already uses.)

[norayr]

i had to comment under the blog post today, and it has the following ways of authentication: livejournal, facebook, twitter, google, mailru, vkontakte and... OPENID!
I have no accounts on the above mentioned services, and I thought - may be I can use my mastodon account as an openid provider, and found this issue.

unfortunately, i cannot, so have no idea how to comment.