OpenID Connect

SWITCH edu-ID supports OpenID Connect which can be conveniently used for the following use cases:

Confidential clients:

  • Server-based web applications

Public clients:

  • Browser-based web applications
  • Mobile apps (AppAuth)
  • Native applications

For security reasons only only the authorization code flow (response_type=code) is supported.

The OpenID Connect protocol is provided by the same Shibboleth IdP instance that also supports SAML. This means that many functionalities known from edu-ID with SAML are also available under OpenID Connect. Common features available with OIDC and SAML include

  • Usage of the same underlying user accounts and attribute information
  • A user encounters the same login user interface
  • A user gets the same user consent
  • support for 2-step authentication

However, there are also some differences: Some attribute names (claims) are different, and client registration requires other OIDC-specific information and it is performed manually for the time being.

It is planned to continuously extend the functionality of the OIDC service. Please contact the edu-ID Team to make suggestions for new features.

Service Registration

First, check the getting started page to make sure that you want to register an OIDC client and that you are entitled to do so.

To register a relying party (a service) send us an e-mail to SWITCH edu-ID support with the following information:

  1. the client type: confidential or public client
  2. the client ID: a unique client id, which is a string without spaces that starts with the name of the home organization responsible for the RP.
    <organisation>_<service name>[_<environment>]

    (<environment> is optional, but SHOULD be _test for test RPs, and MAY be _production or _prod for production RPs)
  3. the client name (optional). This is the name that is displayed on the login window and visible to end users. If not specified, the client ID will be used.
    Uni Demo Student Registration
  4. one or more valid redirect URIs:

    For public clients only: https protocol is mandatory and the app publisher must own the domain of the redirection URI.
  5. the sector identifier URI: To be able to generate the pairwise identifier, the sector identifier URI is needed. Note that only the domain part of the sector identifier is used for the pairwise key generation. It is recommended to choose an URI for a domain that is controlled by the RP operator. This URI may be equal to one of the redirect URIs.
  6. For confidential clients only: use either public key registration or client secret registration.
    • public key client registration: generate a public key and send it to us in jwk format. Supported signing algorithms are: es256 and rs256 with minimal key length: 3072 bits.
      Example for es256:
          "kty": "EC",
          "use": "sig",
          "crv": "P-256",
          "alg": "ES256",
          "x": "G4gRG9lIiwiaW_0r...",
          "y": "rOYGhN-1EGyf9XN6..."

      Example for rs256:
          "kty": "RSA",
          "use": "sig",
          "alg": "RS256",
          "exponent": "AQAB",
          "value": "DqJ-Lcb2voE-5Oks..."
      Public key registration offers the most security and is therefore preferred.
    • client secret registration: specify the method, either client-secret-basic (default), client-secret-post, client-secret-jwt. 
      SWITCH will generate a secret and send it to you over an encrypted channel (i.e. via Threema, Signal).
  7. list of required scopes: (for data protection reasons only scopes that are really justified will be released to RPs)
    profile, email, swissEduIDBase
  8. SWITCH edu-ID environment: test, production or both?
  9. For production services only: the URL of the application or a public description. This information is optional, but highly appreciated to understand the use case and optimize future service developments.
  10. The registration of the RP needs to be confirmed by a Resource Registration Administrator of the operating organization.


  • Public clients MUST use PKCE. When using a confidential client, the usage of PKCE is recommended.
  • The authenticity and legitimacy of clients is ensured:
    • confidential clients, who can keep a secret, store either a private key or a shared secret.
    • public clients, who can't keep a secret, are verified by checking their ownership of the redirection URI.
  • By default, a client will get access to the openid scope and can obtain an id token with it. Please include any additional scopes you require, which will be served from the userinfo endpoint.

IdP Configuration

OIDC IdP configuration and endpoints:




  • implicit and hybrid flows are not supported. Use authorization code flow instead.
  • RPs must be explicitly registered. Dynamic client registration is not supported.