Hosted OIDC Provider
Using the hosted SIWE OIDC Provider
Last updated
Using the hosted SIWE OIDC Provider
Last updated
We deployed an OpenID Connect Provider (OP) with SIWE support hosted under . This deployment is supported by the ENS DAO, under 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 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.
The OP supports the OpenID Connect Provider Configuration specification as per . 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:
To use the hosted OIDC server it is required to register the application as an OIDC client using the OIDC client registration of oidc.signinwithethereum.org. 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:
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:
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 are available. In particular, we make use of the following:
- client_name
;
- logo_uri
; and
- client_uri.