Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow Mastodon to be used as an OpenID provider #4800

Open
Sylvhem opened this issue Sep 4, 2017 · 40 comments
Labels

Comments

@Sylvhem
Copy link
Contributor

@Sylvhem Sylvhem commented Sep 4, 2017

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:


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

This comment has been minimized.

Copy link
Contributor

@Komic Komic commented Sep 4, 2017

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

This comment has been minimized.

Copy link

@remmah remmah commented Sep 4, 2017

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

This comment has been minimized.

Copy link

@urchinhead urchinhead commented Sep 30, 2017

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

This comment has been minimized.

Copy link

@bunnybooboo bunnybooboo commented Dec 19, 2017

What about IndieAuth?

@Openmedianetwork

This comment has been minimized.

Copy link

@Openmedianetwork Openmedianetwork commented Jan 19, 2018

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

@charlycoste

This comment has been minimized.

Copy link

@charlycoste charlycoste commented Mar 27, 2018

@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

This comment has been minimized.

Copy link

@burntout burntout commented Apr 6, 2018

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

@fluffy-critter

This comment has been minimized.

Copy link

@fluffy-critter fluffy-critter commented Dec 15, 2018

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

This comment has been minimized.

Copy link

@fluffy-critter fluffy-critter commented Dec 16, 2018

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

This comment has been minimized.

Copy link
Collaborator

@nightpool nightpool commented Dec 17, 2018

@fluffy-critter

This comment has been minimized.

Copy link

@fluffy-critter fluffy-critter commented Dec 17, 2018

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

This comment has been minimized.

Copy link

@jalcine jalcine commented Jan 3, 2019

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 comment has been minimized.

Copy link

@jfmcbrayer jfmcbrayer commented Feb 3, 2019

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

This comment has been minimized.

Copy link

@aaronpk aaronpk commented Feb 8, 2019

@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

This comment has been minimized.

Copy link

@AlexM4H AlexM4H commented May 23, 2019

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

This comment has been minimized.

Copy link

@SilverWolf32 SilverWolf32 commented Jun 20, 2019

@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

This comment has been minimized.

Copy link

@AlexM4H AlexM4H commented Jun 20, 2019

I think he means OpenID Connect...

@fluffy-critter

This comment has been minimized.

Copy link

@fluffy-critter fluffy-critter commented Jun 20, 2019

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

This comment has been minimized.

Copy link

@SilverWolf32 SilverWolf32 commented Jun 20, 2019

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

This comment has been minimized.

Copy link

@aaronpk aaronpk commented Jun 20, 2019

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

This comment has been minimized.

Copy link

@SilverWolf32 SilverWolf32 commented Jun 20, 2019

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

This comment has been minimized.

Copy link

@fluffy-critter fluffy-critter commented Jun 20, 2019

@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

This comment has been minimized.

Copy link

@SilverWolf32 SilverWolf32 commented Jun 20, 2019

(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

This comment has been minimized.

Copy link

@aaronpk aaronpk commented Jun 20, 2019

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

This comment has been minimized.

Copy link

@AlexM4H AlexM4H commented Jun 20, 2019

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

This comment has been minimized.

Copy link

@johnss johnss commented Jul 2, 2019

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

This comment has been minimized.

Copy link

@fluffy-critter fluffy-critter commented Jul 2, 2019

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

This comment has been minimized.

Copy link

@stale stale bot commented Oct 26, 2019

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.

@stale stale bot added the wontfix label Oct 26, 2019
@trwnh

This comment has been minimized.

Copy link
Contributor

@trwnh trwnh commented Oct 26, 2019

would still be interesting to do

@stale stale bot removed the wontfix label Oct 26, 2019
@fluffy-critter

This comment has been minimized.

Copy link

@fluffy-critter fluffy-critter commented Oct 26, 2019

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

This comment has been minimized.

Copy link

@fluffy-critter fluffy-critter commented Oct 26, 2019

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

This comment has been minimized.

Copy link

@tailot tailot commented Nov 9, 2019

@fluffy-critter Have you evaluated magic link ?

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

@fluffy-critter

This comment has been minimized.

Copy link

@fluffy-critter fluffy-critter commented Nov 9, 2019

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

@johnss

This comment has been minimized.

Copy link

@johnss johnss commented Nov 10, 2019

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

This comment has been minimized.

Copy link

@fluffy-critter fluffy-critter commented Nov 10, 2019

nah

@unmellow

This comment has been minimized.

Copy link

@unmellow unmellow commented Nov 11, 2019

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

@unmellow

This comment has been minimized.

Copy link

@unmellow unmellow commented Nov 11, 2019

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

@fluffy-critter

This comment has been minimized.

Copy link

@fluffy-critter fluffy-critter commented Nov 11, 2019

@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

This comment has been minimized.

Copy link

@unmellow unmellow commented Nov 11, 2019

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

This comment has been minimized.

Copy link

@fluffy-critter fluffy-critter commented Nov 11, 2019

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 indieweb/indieauth#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.)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
You can’t perform that action at this time.