Discourse OpenID Connect

:discourse2: Summary Discourse OpenID Connect allows an OpenID Connect provider to be used as an authentication provider for Discourse.
:hammer_and_wrench: Repository Link https://github.com/discourse/discourse-openid-connect
:open_book: Install Guide How to install plugins in Discourse

Features

The plugin aims to provide a minimal implementation of the specification. Specifically, it supports the “Authorization Code Flow”. To get started, follow the plugin installation instructions, or contact your hosting provider.

Our oauth2-basic plugin can be used for connecting to some openid-connect providers (OpenID Connect is based on OAuth2). However, this plugin should require far less manual configuration, and can make use of the JWT “ID Token” if a JSON API is not available.

Configuration is automatically performed using an OpenID Connect Discovery Document. According to the specification, this should be located at <issuer domain>/.well-known/openid-configuration, but Discourse supports any path to allow for non-compliant implementations (e.g. Azure B2C). The discovery document is cached for 10 minutes, to improve performance on high-traffic sites.

If the discovery document includes a userinfo_endpoint parameter, then the plugin will use that to collect user metadata. If not, the plugin will extract metadata from the id_token (A JWT) supplied by the token endpoint. The plugin DOES NOT verify the authenticity of the JWT signature, as this would significantly increase complexity. This decision is supported by the specification:

If the ID Token is received via direct communication between the Client and the Token Endpoint (which it is in this flow), the TLS server validation MAY be used to validate the issuer in place of checking the token signature.

Configuration

Basic Configuration Options

  • openid_connect_enabled: Enable OpenID Connect authentication

  • openid_connect_discovery_document: OpenID Connect discovery document URL. Normally located at https://your.domain/.well-known/openid-configuration

  • openid_connect_client_id: OpenID Connect client ID

  • openid_connect_client_secret: OpenID Connect client secret

  • openid connect rp initiated logout: Redirect the user to end_session_endpoint after logout. Must be supported by your identity provider and included in the discovery document.

  • openid connect rp initiated logout redirect: (optional) The post_logout_redirect_uri which will be passed to the logout endpoint. If provided, it must be registered with the identity provider.

  • openid_connect_authorize_scope: The scopes sent to the authorize endpoint. This must include ‘openid’

  • openid_connect_verbose_logging: Log detailed openid-connect authentication information to /logs. Keep this disabled during normal use.

Advanced Configuration Options

  • openid_connect_token_scope: The scopes sent when requesting the token endpoint. The official specification does not require this.

  • openid_connect_error_redirects: If the callback error_reason contains the first parameter, the user will be redirected to the URL in the second parameter. Used for unusual implementations that send errors in response to user input (e.g. Azure B2C)

  • openid_connect_allow_association_change: Allow users to disconnect and reconnect their Discourse accounts from the OpenID Connect provider

Example setup

Here we will set up the openid-connect plugin to connect to Google’s OpenID Connect provider. This replicates functionality that already exists in the core of Discourse, but it serves as an accessible example.

  1. Head to OpenID Connect  |  Google Identity  |  Google Developers and follow the instructions to obtain OAuth Credentials.

  2. On the same page, follow the instructions to add a redirect URI. This should be https://<your_forum>/auth/oidc/callback (without a trailing slash)

  3. Go to your Discourse site settings and search for “openid_connect”

    • openid connect enabled:

    • openid connect discovery document: https://accounts.google.com/.well-known/openid-configuration

    • openid connect client id: <client-id>

    • openid connect client secret: <client-secret>

    • openid connect authorize scope: openid email (with a space in between)

  4. You’re done. The “Login with OpenID Connect” button will now log in using Google :tada:. These same steps can be applied to other providers, with very minimal changes.

Debugging

In addition to the verbose_logging setting described above, you can access data about OIDC associations using the data-explorer plugin:

SELECT user_id, provider_name, provider_uid
FROM user_associated_accounts
WHERE provider_name = 'oidc'

Or on the rails console:

User.find_by_username("david").user_associated_accounts.where(provider_name: 'oidc')

Provider Specific Notes

Please feel free to update this if you find any provider-specific quirks relating to this integration:

Azure AD

Add the email scope, and make sure you’re using the version 2 endpoint configuration document. For example

https://login.microsoftonline.com/{tenant}/v2.0/.well-known/openid-configuration
Azure B2C

The discovery document URL details can be found here: Web sign in with OpenID Connect - Azure Active Directory B2C | Microsoft Learn

To make emails work:

Yahoo
  1. Head to Yahoo and create a new app

  2. Enter the Application Name, and set the callback domain to your forum domain (e.g. meta.discourse.org)

  3. Under API Permissions, choose Profiles: Read/Write Public and Private. This is the only way I know of to obtain the user email address

  4. Save the app

  5. In the Discourse OIDC settings, set the discovery document to

    https://login.yahoo.com/.well-known/openid-configuration
    
  6. Enter the client ID and secret from Yahoo

  7. Enable the OIDC plugin

AWS Cognito
  1. Go to Cognito and select or create a new user pool.
  2. Define an app in App clients.
  3. Leave everything to default, but change Auth Flows Configuration to only select ALLOW_REFRESH_TOKEN_AUTH.
  4. Go to app client settings and select the new app.
  5. Change the callback URL to https://yoursite.example.com/auth/oidc/callback.
  6. Only check the Authorization code grant flow among “Allowed OAuth Flows”.
  7. Check all scopes needed (I have all checked).
Okta
  1. Configure Discourse with your Okta app client ID and secret

  2. Set the discovery document URL to

    https://{your-app}.okta.com/.well-known/openid-configuration
    
  3. In Discourse, set the openid connect authorize scope to openid email

CHANGELOG

TODO

36 Likes
Native SSO with Azure AD
How to setup okta authentication with discourse
OpenIdAuthenticator plugin fails
Sign in to Discourse using ORCID
Discourse Login using external API
OpenID Connect support in selfhosted Discourse instance
OpenID connect plugin
Discourse, Keycloak, SAML vs OAuth
Auto-sign-in with the OpenId Connect Plugin and AWS Cognito
Tutorial for OpenID Connect / Azure AD
Is "partial" SSO possible?
Setup DiscourseConnect - Official Single-Sign-On for Discourse (sso)
Keycloak SSO and logout issue
SSO Login page not showing up
Installing own gem in plugin
Official support for Microsoft Azure AD?
Enabling Okta for employees only through OpenID Connect Authentication Plugin
Azure AD Authentication and Creation of User Account
OpenIdAuthenticator plugin fails
SSO with TownNews CMS
Removing Yahoo login from Core, and deprecating OpenID 2.0
Availability of OpenID Connect in hosted plans
./launcher rebuild app fails hard 'bundle exec rake db:migrate' possible issue with github/master repo removal of auth/oath2_authenticator
Error of Discourse OpenID Connect
How to set-up Discourse with Atricore Josso CE
ADFS Authentication
Can I include website analytics in trust data?
SAML Plugin on Self Hosted Discourse
Anyone have a working AWS Cognito configuration w/ ouath2, openid or sso?
OAuth connection of discourse
Failed to bootstrap due to out of memory killer
Availability of OpenID Connect in hosted plans
OpenID Connect Plugin not creating new users with AWS Cognito
Restrict Office 365 Login to certain Group
AAD integration with Discourse
Custom Login Flow: AWS Cognito SSO (via Passwordless Signin) - Is this possible?
User (patron) getting authorization error message
Azure OpenID Connect Authentication Plugin
IndieAuth login
Intergrate Discourse with keycloak
How can you connect firebase to discourse?
Can we use the default atlassian id to login to discourse
OpenID with line.biz - email in JWT , missing in userinfo

I installed openID plugin and our IT configured everything needed (added also username and email claims) but unfortunately every new user must always register first and activate account with the email.

Is there any trick to avoid this and use directly username and email for SSO?

Thank you very much.

Regards,
Daniela

Hi Daniela! Welcome. :wave: Sounds to me like you need to review your settings. Is the external auth provider one one of the ones with instructions above, or different?

Can you tell me how these settings are set? This is what works for me, using Okta as the external auth provider. I would be careful about deselecting enable_local_logins until everything else is working and you know you are able to log in via openid.

  • openid_connect_enabled → SELECTED
  • openid_connect_discovery_document → https://=okta_subdomain=.okta.com/.well-known/openid-configuration
  • openid_connect_client_id → Client id from Okta App page
  • openid_connect_client_secret → Client secret from Okta App page
  • openid_connect_overrides_email → SELECTED
  • openid_connect_authorize_scope → openid email profile
  • enable_local_logins → NOT selected
  • enable_local_logins_via_email → NOT selected
  • email_editable → NOT selected
  • openid connect rp initiated logout → SELECTED
  • auth_overrides_email → SELECTED
  • auth_overrides_username → SELECTED
  • auth_overrides_name → SELECTED
  • auth_immediately → SELECTED
  • auth_skip_create_confirm → SELECTED

@tobiaseigen Thank you very much for your quick help!
We had missing settings in auth part. It is working properly now.

Thank you.

1 Like

Hi, I’ve a Discourse forum that was configured to use this plugin, but we have since needed to change the domain name used for the Discourse site and SSO is currently not working as a result, however we can’t use a Discourse regular login to access the site – is there a way we could use the rails console to deactivate the plugin so we can login to Discourse not using SSO and then get everything working again?

I think the [YourSite]u/admin-login/ link can bypass SSO. :+1:

3 Likes

Hi there,
we are using the OpenID Connect Authentication Plugin with a Discourse installation on AWS.
We have deployed the containers Discourse, Discourse Sidekiq and Redis (Based on Bitnami but please don’t kick me out ;). The DB is running on AWS RDS. We use KeyCloak.

Things do run.

But sometimes after a restart of the Discourse AWS Task it happens that it thinks that it has the Discovery document in the cache but then there is no doc there. And it does not try to re-retrieve it from KeyCloak:

OIDC Log: Discovery document loaded from cache
OIDC Log: Discovery document is
---
(oidc) Request phase initiated.
(oidc) Authentication failure! openid_connect_discovery_error: OmniAuth::OpenIDConnect::DiscoveryError, Discovery document is missing

In the browser app I see: Unable to fetch configuration from identity provider. Please try again.

What can you advise ?

Is there a way to handle identity management from the idP? This is great for SSO, and JIT. I would like to take deprovisioning steps based on identity state. Normally, this would be a SCIM integration, not sure if Discourse supports SCIM

1 Like

Do you mean Okta? There are settings in the OP. (There are way too many TLAs in your post btw :D)

Sorry for that :frowning: I am looking for a way to manage the internal identities (employees) on our community board. Main reason is for the timely suspension of accounts that are no longer working for the company.

With SCIM (Standard for Cross domain Identity Management) it will update the user to “Suspended” if the identity in Okta (or any identity provider) is deactivated. OpenID Connect or SAML doesn’t support that irc. This is likely not the right thread to ask this question though.

Hi @danibe i am facing exactly the same issue. Would you be kind to advise what “missing settings in auth part” i might be missing?

thanks

Found the issue: email_verified was found false and fixed on the Keycloak side :see_no_evil:

@david Does above steps works with User flows in Azure B2C, which are pre-built policy for use cases.

Email address doesn’t get populated in the new user dialog when the authorization is returned. Using a standard user flow to manage the sign-up experience, but the claim is returning something labeled as “emails” and it’s a stringcollection, not a single email.

Setting up openid_connect_authorize_scope to openid emails also doesn’t work.

This plugin is built to work with standards-compliant OIDC services. That means the email should be returned in an “email” field.

If you check the “Azure B2C” section in the first post of this topic, there are some community-provided instructions for setting up a “custom policy” which puts the email address in a standards-compliant location. I’m afraid I’m not familiar enough with Azure B2C to know whether that will work with the “user flows” feature.

1 Like

Thank you @david, it works with custom policy, was hoping to go with much easier route of User flows, but that is out of our control to change.

Few of the suggestions for plugin:

  • Both Sign and Signup button redirect user to login page, in Azure B2C different page can be shown by appending parameter
1 Like

Hello,

Is there a way to set the discourse user avatar source to a field which is specified in the openID service?

Edit: we’re using keycloak

Hello,

I have a requirement similar to @Tomáš_Guba one : I would like to get value from a custom entry in user profile and use it in a [custom] user field.

In my personal case, i have a discovery document with a userinfo_endpoint

Is there something like that in the plugin roadmap ?

Thanks

Hi,

Is it intended that a user is still able to login with the local password? Let’s say a user creates an account via oidc login. At this point everything is fine, the user can log in via the oidc provider and the account is protected via 2fa enforcement on the oidc provider as well.

Now, the user set a local password for this oidc connected account via the password reset email feature. After setting the password, login is possible using the local password and oidc, but the local login is not 2fa protected and potentially insecure. To make it even worse there seems to be no way back, after setting a local password users can’t remove it again, and they can also not setup 2fa because this will disable social logins. I would like to have an option to disallow local logins for oidc users and to be even more strict an option to disallow all other social logins as well to make oidc login mandatory for oidc connected accounts.

Thanks.

Just to check - did you toggle the enable local logins admin setting?

That will disable local login for everyone, not what I want :slight_smile:

Usecase:

  • Mandatory login via oidc for employees
  • Community login via social login or local user registration
1 Like