-
-
Notifications
You must be signed in to change notification settings - Fork 6.9k
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 login through OpenID #7958
Comments
Not just this, but it would also prevent the need for the mastodon instance to host and secure usernames and passwords. Managing accounts, forgotten passwords, "hacked" accounts, etc. is a pain. I'd much rather leave this to the IdP to deal with. |
|
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. |
|
Bump to not have this issue closed by the stale bot. The suggestion is still valid ;) |
|
I too would like to give this feature a bump. OIDC is more useful than SAML for environmental like AWS. |
|
Hey folks #16221 has landed and I'm testing it as much as possible to help it get merged. Any other folks who can lend a hand with docs / reviews / testing / etc.? That would be great. |
|
We're testing this and one doubt we still have if is there's a clever way to migrate / merge users who registered before enabling EDIT: Variables used for configuration: |
|
@decentral1se @teutat3s can this be extended to allow an input text area for IDP, rather than constraining to a single IDP? This could then be used to interop with Solid & WebID's that contain a Let me know if there's anything needed from the Solid side (I work at Inrupt, one of the companies helping build Solid) |
|
Also worth mentioning is the new OIDC Federation spec, there's some discussion here on that from the Solid side: solid/solid-oidc#207 |
|
Iʻve studied this and think itʻs time for a warning: DO NOT DO THIS if you think there may be the possibility that the account identifiers so created might ever want to be claimed for any other reason. Deleting an account created through OIDC UID or other SSO identifiers will render that UID permanently unavailable in the future. This is an undesirable feature in my opinion and I have filed issue #21071 to raise the topic for further investigation. I also endorse the comment above. #7958 (comment) as OIDC Federation both in principle and in practice can improve the federation experience for both users and server admins. |
|
Is it possible not to create new account if the existing user doesn't exist yet? |
I am actually wondering the same thing |
|
Had you considered using OpenID-2.0 too or would that belong to a different ticket ? I mention because OpenID-2.0 is already federated and providers are here already and different services already allow logging in via OpenID-2.0, for example: |
|
I'd say so, so this could be closed as completed @vmstan. Adoption of something like OIDC Federation or similar could be a future thing. |
OpenID is a decentralized authentication system. It allows to delegate the authentication to a third party trusted by the end-user. The last version (OpenID Connect) works over OAuth 2.0. It's alrady used by a lot of websites, but usually limited to a few big providers like Google or Facebook (don't ask why...).
Allowing to login on Mastodon through OpenID would also prevent to have to remember another login/password.
For reference, @Sylvhem has submitted a request to add an OpenID provider in Mastodon: #4800.
The text was updated successfully, but these errors were encountered: