Hosted OIDC Provider

Using the hosted SIWE OIDC Provider


We deployed an OpenID Connect Provider (OP) with SIWE support hosted under This deployment is supported by the ENS DAO, under EP-10 in order to have a DAO-governed OpenID Connect Provider.
Developers will be able to use a standard OIDC client to connect to the hosted OP. Please see our OIDF Conformance Test Report for more information about supported OIDC features.
To use the hosted OP, developers are typically interested in the following steps:
  • Retrieving the OP configuration.
  • Registering the OIDC client with the OP.
  • Using the OP configuration to configure the OIDC client.

OpenID Connect Provider Configuration

The OP supports the OpenID Connect Provider Configuration specification as per OpenID Connect Discovery . To fetch the OP configuration which is required for configuring OIDC clients, developers can make a GET HTTPS request to the following endpoint as follows:
This will result in the latest OP configuration object that provides information about supported OIDC flows, endpoints, public keys, signing algorithm, client authentication types, etc. as follows:
"token id_token"

OpenID Connect Client Registration

To use the hosted OIDC server it is required to register the application as an OIDC client using the OIDC client registration of Currently, no user interface for OIDC client registration is supported. For that reason, developers will need to use the REST API.
To register a new OIDC client, the following request has to be adapted:
curl -X POST
-H 'Content-Type: application/json'
-d '{"redirect_uris": ["https://<your.comaind>/cb"]}'
The OIDC server needs to know whether the user is allowed to be redirected to the URI in the OIDC request after authentication for the specific OIDC client. This must be configured through the redirect_uris parameter.
The response will be a OIDC client metadata object that contains the client_id and client_secret that have to be used to retrieve the OIDC tokens from the token endpoint. Developers have to make sure that those parameters have to be kept secret.
The following is an example response:
"client_id": "9b49de48-d198-47e7-afff-7ee26cbcbc95",
"client_secret": "er...",
"registration_access_token": "2a...",
"registration_client_uri": "",
"redirect_uris": ["https://<your.domain>/cb"]
A client can then be updated or deleted using the registration_client_uri with the registration_access_token as a Bearer token.
A variety of metadata options are available. In particular, we make use of the following: - client_name; - logo_uri; and - client_uri.