Skip to main content
Version: On prem: 14.0.16

OpenID and OpenID Connect

DISCLAIMER


This page contains third-party references. We strive for our content to always be up-to-date, however, the content referring to external vendors may change independently of Omada. If you spot any inconsistency, please report it to our Helpdesk.

About OpenID and OpenID Connect

OpenID allows you to use an existing account to sign in to multiple websites without the need to create new passwords.

If you want to, you can choose to associate information with your OpenID that you can share with the websites that you visit, such as a name or an email address. OpenID allows you to control how much of that information is shared with the websites that you visit.

When you use OpenID, your password is only given to your identity provider, and that provider then confirms your identity on the website that you visit. Apart from your provider, no other website sees your password, eliminating the chance that an insecure website compromises your identity.

OpenID Connect is an identity layer on top of the OAuth 2.0 protocol that allows clients to:

  • Verify the identity of the end-user, based on the authentication completed by an authorization server

  • Obtain basic profile information about the end-user in an interoperable and REST-like manner.

OpenID Connect allows clients of all types, including web-based, mobile, and JavaScript clients, to request and receive information about authenticated sessions and end-users.

About OpenID Connect Request

The OpenID Connect request contains a scope variable. The first value of the scope is always openid.

Secondly, if you use the scope email in the scopes_supported variable of the OpenID Connect metadata, then email is attached to the end of the requested scope. Apart from the elements above, you cannot configure the request scope.

About the JWT Response

Omada Identity validates the signature of the JWT response based on the signing keys provided in the metadata. Secondly, the nonce of the JWT is validated against a nonce stored in a temporal browser cookie.

When it takes the user name from the JWT, Omada IdentityClosed iterates over the claims provided in the JWT. By default, Omada Identity looks for these claims:

email,upn,given_name,preferred_username,sub

The first non-empty value is used as the user name. You can customize the list of claims to look for by using the customer setting named OpenIDClaimTypes.

If a particular claim should be the trusted user name, you must configure the customer setting. Similarly, if a particular claim is not trusted, you must remove it from the list using the customer setting.