This works! 🔥 🔥 🔥

I published this image decentral1se/hometown:v1.0.5_3.4.0_openid-sso (latest masto/hometown + this patch).

Example vars:

# OpenID Connect
# --------------
# OIDC_ENABLED=
# OIDC_DISPLAY_NAME=
# OIDC_ISSUER=
# OIDC_DISCOVERY=
# OIDC_CLIENT_AUTH_METHOD
# OIDC_SCOPE=
# OIDC_RESPONSE_TYPE=
# OIDC_RESPONSE_MODE=
# OIDC_DISPLAY=
# OIDC_PROMPT=
# OIDC_SEND_NONCE=
# OIDC_SEND_SCOPE_TO_TOKEN_ENDPOINT=
# OIDC_IDP_LOGOUT_REDIRECT_URI=
# OIDC_UID_FIELD=
# OIDC_CLIENT_ID=
# OIDC_REDIRECT_URI=
# OIDC_HTTP_SCHEME=
# OIDC_HOST=
# OIDC_PORT=
# OIDC_AUTH_ENDPOINT=
# OIDC_TOKEN_ENDPOINT=
# OIDC_USER_INFO_ENDPOINT=
# OIDC_JWKS_URI=
# OIDC_END_SESSION_ENDPOINT=
# OIDC_SECURITY_ASSUME_EMAIL_IS_VERIFIED=

Example minimal working env var config (Keycloak SSO v12.0.4):

OIDC_ENABLED=true
OIDC_DISPLAY_NAME="example.space"
OIDC_ISSUER=https://login.example.space/auth/realms/example-space
OIDC_DISCOVERY=true
OIDC_SCOPE="openid,profile"
OIDC_UID_FIELD=uid
OIDC_CLIENT_ID=masto-oidc
OIDC_REDIRECT_URI=https://social.example.space/auth/auth/openid_connect/callback
OIDC_SECURITY_ASSUME_EMAIL_IS_VERIFIED=true
OIDC_CLIENT_SECRET=...

Hey @chandrn7 let me know if you need any further testing on this, can support. Thanks again 🚀

One bug: user autocompletion in the UI doesn't work unfortunately. Can you confirm @chandrn7?

EDIT: actually, it seems OpenID Connect based accounts can't get @ autocompletion for local accounts? So a SSO logged in user cannot get autocomplete for @'s to their local instance admin (which is a local account). We're still testing this out.

EDIT EDIT: Upon further testing, it seems only the first admin account is not @'able? We've tested with an additional local account and it works. The first admin account was created with tootctl accounts create admin --email [email protected] --confirmed --role admin. All other functionality seems to be working!

Thanks for the help @decentral1se! I have tested it with different OpenID providers and have been using the code on an instance without issue, but any ideas you have for testing would be appreciated. I'm planning on working on a documentation pull request if the changes are merged. My minimal working env var config looks similar to yours:

OIDC_ENABLED=true
OIDC_DISPLAY_NAME=phantauth
OIDC_ISSUER=https://phantauth.net
OIDC_DISCOVERY=true
OIDC_SCOPE=openid,profile,email
OIDC_UID_FIELD=preferred_username
OIDC_CLIENT_ID=test.client
OIDC_CLIENT_SECRET=...
OIDC_REDIRECT_URI=https://example.social/auth/auth/openid_connect/callback

As for the @ autocomplete, I haven't come across that issue. Could you give me some more detail? When you say @ autocomplete are you talking about @ functionality while posting or somewhere else?

As for the @ autocomplete, I haven't come across that issue. Could you give me some more detail? When you say @ autocomplete are you talking about @ functionality while posting or somewhere else?

Where my initial admin account created with tootctl accounts create autonomic --email [email protected] --confirmed --role admin doesn't get autocompleted when trying to post. However, we created an additional local account via invite mail and you can get autocomplete on that. I am wondering if there is some special state for the first user created that is breaking something here? I am not sure. Could it be a difference in the OIDC_* config? I doubt it also. Anyway, maybe you can reproduce?

Can confirm that this doesn't break Tusky client logins either 💯

Where my initial admin account created with tootctl accounts create autonomic --email [email protected] --confirmed --role admin doesn't get autocompleted when trying to post. However, we created an additional local account via invite mail and you can get autocomplete on that. I am wondering if there is some special state for the first user created that is breaking something here? I am not sure. Could it be a difference in the OIDC_* config? I doubt it also. Anyway, maybe you can reproduce?

I wasn't able to reproduce it. Have you tried to replicate using a non-OIDC account? Maybe it's unrelated?

Feature request: some option to set the "home page" (the thing that redirects to the /about URI) to /auth/sign_in by default so people can get the "Login with ..." option somewhere more easily. Currently, it is very difficult to understand where to go from the about page without some custom text? (This can be handled by setting LIMITED_FEDERATION=true but that has large implications and it is also a bit broken right now #16221 (comment))

Also is there any indication that this will be merged? We're running it in testing with no problems for a while now.

I found it hard to find the SSO login buttons as well, so I have a branch where I add them to the /about page. I could create a separate pull request? Or add it to this one?

No idea about the possibility of it being merged. @ClearlyClaire?

Except for the fact that the Keycloak login is only on /auth/sign_in instead of the home /about page, this works perfectly on Arch Linux!

For those of you who can't wait for this to be merged, you can add a line in the AUR package's PKGBUILD to patch with this PR. See this ArchWiki page for more information.

Most recent commits added SSO buttons to the /about page as requested.

@chandrn7 Showing a conflict on Gemfile.lock

@weex Should be resolved now.

omg is this getting merged 👁️ 🙏

Nice!

Cause I didn't found the solution directly in here, just in linked issues, for everyone still experience OpenSSL / Certificate issues while trying to login via OpenID Connect, I followed this change (on an Ubuntu Server):
ln -sf /etc/ssl/certs/ca-certificates.crt $mastodon/vendor/bundle/ruby/3.0.0/gems/httpclient-2.8.3/lib/httpclient/cacert.pem
you may replace 3.0.0 version id with your setup, also possible to create backup of cacert.pem if you want to stay on the save site trying this.

The certificate issue is caused by dependency gitlab-omniauth-openid-connect, since they have not fixed it, bumping dependency version does not work for now. Have filed an issue at https://gitlab.com/gitlab-org/gitlab-omniauth-openid-connect/-/issues/4

I found a fix for the certificate issue after much research here https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/30749/diffs. I added it to my local code to get httpclient to respect my openssl config. It's been working well for me.

We've discovered on our server two bugs related to OIDC. I'm wondering if they're deserving of new issues or should be discussed here.

1. Logout does not go to the discovered OIDC end session
2. Signup does not properly link to the registration page

For logout, the expected behavior when a user clicks "Logout" is that the application (Mastodon) should send them to the OIDC end_session_endpoint, which is a key in the OIDC Discovery document. This will tell the Identify Provider to end the current user session.

The current behavior on our system is that it simply presents a user a logout page, but since they're still logged into the identity provider, going back to Mastodon shows them as logged in.

The second issue is that signup on OIDC should take the user to a user registration page. With keycloak I believe this is https://{keycloak_server}/auth/realms/{realm}/login-actions/registration?client_id={client_id}

I'm less sure about this being correct, or discoverable, but the current behavior is that the signup button is present but non-functional.

I'm trying to reproduce the same thing, but with Authentik instead of Keycloak.
I'm inspired by what's been said here in this conversation and by this little bit of documentation on the GoAuthentik.io website about integration with Mastodon :
https://goauthentik.io/integrations/services/mastodon/
But unfortunately, I couldn't get it to work.

Particularly for OIDC_ISSUER, I guess it should point to https://authentik.company/ (of course with my own Authentik FQDN), but is the site root enough or does it need a path?

EDIT :
I think I found the solution:
OIDC_CLIENT_ID and OIDC_CLIENT_SECRET are generated when creating the Provider in Authentik, that was obvious right away.
When creating the Provider in Authentik, we have to expand "Advanced protocol settings", search for "Subject mode" and select "Based on the User's username".
And about the two variables I didn't understand, this seems to work :
OIDC_ISSUER=https://authentik.company/application/o/mastodon/
OIDC_AUTH_ENDPOINT=https://authentik.company/application/o/mastodon/.well-known/openid-configuration
Can work with this too : OIDC_AUTH_ENDPOINT=https://authentik.company/application/o/authorize/

I also realized that if I put a "é" in OIDC_DISPLAY_NAME, Mastodon will show the mamouth smashing his computer when connecting (Error)...

BTW, why there is nothing about OIDC_* at the environment variables list in the doc?
https://docs.joinmastodon.org/admin/config/#external-authentication

I also realized that if I put a "é" in OIDC_DISPLAY_NAME, Mastodon will show the mamouth smashing his computer when connecting (Error)...

This sounds like a separate issue worth reporting! As always, please join traces from mastodon-web's logs in this case.

Has anything changed in the way Mastodon handles OpenID since, > 4.2.0? Had my instance running well with SSO via authentik and now just get a blank screen when trying to log in via Single Sign-on? Already filed this at authentik (goauthentik/authentik#7372)?

It's possible there have been Content-Security-Policy related changes. Which browser are you using? Do you have anything in the browser console?

It's possible there have been Content-Security-Policy related changes. Which browser are you using? Do you have anything in the browser console?

Same issue with latest Safari and Firefox 119.0. Firefox' browser console shows the following errors which I cannot allocate or understand:

Those errors do not seem related—at least not on the Mastodon side of things. I'm not sure what could cause this.

Those errors do not seem related—at least not on the Mastodon side of things. I'm not sure what could cause this.

That's what I thought as well, so I went to debug the issue a little bit further - that's a refined output, maybe this helps?

The nginx.conf is used from https://github.com/mastodon/mastodon/blob/main/dist/nginx.conf without any changes except the Let's Encrypt-certificates.

So I have this connected now after a bit of fiddling, however my user that already existed on the mastodon server has the same email address as the one that exists in KeyCloak. This then presents me with: Error creating an account for this identity.

Should this happen or should it prompt me to merge accounts on the mastodon server?

@richarvey See this comment/issue: #20144 (comment)

TLDR: it is not currently supported, but you might be able to do a manual migration.

@richarvey you may want to try with ALLOW_UNSAFE_AUTH_PROVIDER_REATTACH=true, see https://docs.joinmastodon.org/admin/config/#allow_unsafe_auth_provider_reattach

How can i add mutiple OIDC providers?