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

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 with 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 OIDC-specific information.

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

OICD Implementation in Switch edu-ID

  • For security reasons, only the authorization code flow (response_type=code) is supported.
  • Relying Parties must be explicitly registered using the Resource Registry. More details can be found at Service Registration. Dynamic client registration is not supported.
  • The authenticity and legitimacy of clients is ensured for:
    • confidential clients, who can keep a secret, by storing either a private key or a shared secret.
    • public clients, who can't keep a secret, by checking their ownership of the redirection URI. In addition, public clients MUST use PKCE.
  • The OpenID Providers (OPs) publish their configuration on the respective endpoints listed below. Relying parties are expected to fetch the configuration (and further endpoints like the keyset endpoint) regularly and to not use a static snapshot of it. Otherwise, operation of the relying party could fail when for instance signing keys are rotated:

References