This documentation site is for the versions of Synapse maintained by the Matrix.org Foundation (github.com/matrix-org/synapse), available under the Apache 2.0 licence.
Synapse can be configured to use an OpenID Connect Provider (OP) for
authentication, instead of its own local password database.
Any OP should work with Synapse, as long as it supports the authorization code
flow. There are a few options for that:
start a local OP. Synapse has been tested with Hydra and
Dex. Note that for an OP to work, it should be served under a
secure (HTTPS) origin. A certificate signed with a self-signed, locally
trusted CA should work. In that case, start Synapse with a SSL_CERT_FILE
environment variable set to the path of the CA.
set up a SaaS OP, like Google, Auth0 or
Okta. Synapse has been tested with Auth0 and Google.
The OpenID integration in Synapse uses the
authlib library, which must be installed
as follows:
The relevant libraries are included in the Docker images and Debian packages
provided by matrix.org so no further action is needed.
If you installed Synapse into a virtualenv, run /path/to/env/bin/pip install matrix-synapse[oidc] to install the necessary dependencies.
For other installation mechanisms, see the documentation provided by the
maintainer.
To enable the OpenID integration, you should then add a section to the oidc_providers
setting in your configuration file.
See the configuration manual for some sample settings, as well as
the text below for example configurations for specific providers.
This lets the OpenID Connect Provider notify Synapse when a user logs out, so that Synapse can end that user session.
This feature can be enabled by setting the backchannel_logout_enabled property to true in the provider configuration, and setting the following URL as destination for Back-Channel Logout notifications in your OpenID Connect Provider: [synapse public baseurl]/_synapse/client/oidc/backchannel_logout
Azure AD can act as an OpenID Connect Provider. Register a new application under
App registrations in the Azure AD management console. The RedirectURI for your
application should point to your matrix server:
[synapse public baseurl]/_synapse/client/oidc/callback
Go to Certificates & secrets and register a new client secret. Make note of your
Directory (tenant) ID as it will be used in the Azure links.
Edit your Synapse config file and change the oidc_config section:
- idp_id: apple
idp_name: Apple
issuer: "https://appleid.apple.com"
client_id: "your-client-id" # Set to the "identifier" for your "ServicesID"
client_auth_method: "client_secret_post"
client_secret_jwt_key:
key_file: "/path/to/AuthKey_KEYIDCODE.p8" # point to your key file
jwt_header:
alg: ES256
kid: "KEYIDCODE" # Set to the 10-char Key ID
jwt_payload:
iss: TEAMIDCODE # Set to the 10-char Team ID
scopes: ["name", "email", "openid"]
authorization_endpoint: https://appleid.apple.com/auth/authorize?response_mode=form_post
user_mapping_provider:
config:
email_template: "{{ user.email }}"
Set the Allowed Callback URLs to [synapse public baseurl]/_synapse/client/oidc/callback
Add a rule with any name to add the preferred_username claim.
(See https://auth0.com/docs/customize/rules/create-rules for more information on how to create rules.)
Create a provider in Authentik, with type OAuth2/OpenID.
The parameters are:
Client Type: Confidential
JWT Algorithm: RS256
Scopes: OpenID, Email and Profile
RSA Key: Select any available key
Redirect URIs: [synapse public baseurl]/_synapse/client/oidc/callback
Create an application for synapse in Authentik and link it to the provider.
Note the slug of your application, Client ID and Client Secret.
Note: RSA keys must be used for signing for Authentik, ECC keys do not work.
Synapse config:
oidc_providers:
- idp_id: authentik
idp_name: authentik
discover: true
issuer: "https://your.authentik.example.org/application/o/your-app-slug/" # TO BE FILLED: domain and slug
client_id: "your client id" # TO BE FILLED
client_secret: "your client secret" # TO BE FILLED
scopes:
- "openid"
- "profile"
- "email"
user_mapping_provider:
config:
localpart_template: "{{ user.preferred_username }}"
display_name_template: "{{ user.preferred_username|capitalize }}" # TO BE FILLED: If your users have names in Authentik and you want those in Synapse, this should be replaced with user.name|capitalize.
Dex is a simple, open-source OpenID Connect Provider.
Although it is designed to help building a full-blown provider with an
external database, it can be configured with static passwords in a config file.
django-oauth-toolkit is a
Django application providing out of the box all the endpoints, data and logic
needed to add OAuth2 capabilities to your Django projects. It supports
OpenID Connect too.
Configuration on Django's side:
Add an application: https://example.com/admin/oauth2_provider/application/add/ and choose parameters like this:
Facebook do have an OIDC discovery endpoint,
but it has a response_types_supported which excludes "code" (which we rely on, and
is even mentioned in their documentation),
so we have to disable discovery and configure the URIs manually.
GitHub is a bit special as it is not an OpenID Connect compliant provider, but
just a regular OAuth2 provider.
The /user API endpoint
can be used to retrieve information on the authenticated user. As the Synapse
login mechanism needs an attribute to uniquely identify users, and that endpoint
does not return a sub property, an alternative subject_claim has to be set.
Gitea is, like Github, not an OpenID provider, but just an OAuth2 provider.
The /user API endpoint
can be used to retrieve information on the authenticated user. As the Synapse
login mechanism needs an attribute to uniquely identify users, and that endpoint
does not return a sub property, an alternative subject_claim has to be set.
Create a new application.
Add this Callback URL: [synapse public baseurl]/_synapse/client/oidc/callback
Synapse config:
oidc_providers:
- idp_id: gitea
idp_name: Gitea
discover: false
issuer: "https://your-gitea.com/"
client_id: "your-client-id" # TO BE FILLED
client_secret: "your-client-secret" # TO BE FILLED
client_auth_method: client_secret_post
scopes: [] # Gitea doesn't support Scopes
authorization_endpoint: "https://your-gitea.com/login/oauth/authorize"
token_endpoint: "https://your-gitea.com/login/oauth/access_token"
userinfo_endpoint: "https://your-gitea.com/api/v1/user"
user_mapping_provider:
config:
subject_claim: "id"
localpart_template: "{{ user.login }}"
display_name_template: "{{ user.full_name }}"
Keycloak is an opensource IdP maintained by Red Hat.
Keycloak supports OIDC Back-Channel Logout, which sends logout notification to Synapse, so that Synapse users get logged out when they log out from Keycloak.
This can be optionally enabled by setting backchannel_logout_enabled to true in the Synapse configuration, and by setting the "Backchannel Logout URL" in Keycloak.
Create an OpenID Connect Relying Parties in LemonLDAP::NG
The parameters are:
Client ID under the basic menu of the new Relying Parties (Options > Basic > Client ID)
Client secret (Options > Basic > Client secret)
JWT Algorithm: RS256 within the security menu of the new Relying Parties
(Options > Security > ID Token signature algorithm and Options > Security > Access Token signature algorithm)
Scopes: OpenID, Email and Profile
Allowed redirection addresses for login (Options > Basic > Allowed redirection addresses for login ) :
[synapse public baseurl]/_synapse/client/oidc/callback
Synapse config:
oidc_providers:
- idp_id: lemonldap
idp_name: lemonldap
discover: true
issuer: "https://auth.example.org/" # TO BE FILLED: replace with your domain
client_id: "your client id" # TO BE FILLED
client_secret: "your client secret" # TO BE FILLED
scopes:
- "openid"
- "profile"
- "email"
user_mapping_provider:
config:
localpart_template: "{{ user.preferred_username }}}"
# TO BE FILLED: If your users have names in LemonLDAP::NG and you want those in Synapse, this should be replaced with user.name|capitalize or any valid filter.
display_name_template: "{{ user.preferred_username|capitalize }}"
Mastodon instances provide an OAuth API, allowing those instances to be used as a single sign-on provider for Synapse.
The first step is to register Synapse as an application with your Mastodon instance, using the Create an application API (see also here). There are several ways to do this, but in the example below we are using CURL.
This example assumes that:
the Mastodon instance website URL is https://your.mastodon.instance.url, and
Synapse will be registered as an app named my_synapse_app.
Send the following request, substituting the value of synapse_public_baseurl from your Synapse installation.
curl -d "client_name=my_synapse_app&redirect_uris=https://[synapse_public_baseurl]/_synapse/client/oidc/callback" -X POST https://your.mastodon.instance.url/api/v1/apps
You should receive a response similar to the following. Make sure to save it.
As the Synapse login mechanism needs an attribute to uniquely identify users, and Mastodon's endpoint does not return a sub property, an alternative subject_template has to be set. Your Synapse configuration should include the following: