OpenID Connect (OIDC) is an identity layer built on top of the OAuth 2.0 framework. OIDC allows applications to verify the identity of an end-user and obtain basic user profile information. OAuth allows applications to obtain JWT access tokens for use as authorization to invoke resource server APIs on behalf of users. You can configure your applications so that they are accessible to only specific resource server APIs. Identity as a Service supports both OIDC and OAuth (2.0 and 2.1).
Passkey login is available for OIDC and OAuth applications. For more information, see Manage Passkey/FIDO2 authenticators.
The following summarizes OIDC and OAuth roles based on these specifications:
● Resource Owner—The user who authenticates with an Authorization Server (Identity as a Service in this case) or grants access to a client application protected resource server API at the Resource Server.
● Resource Server—The resource server that provides the protected resource server URLs/APIs. The Resource Server requires JWT access tokens issued by the Authorization Server (Identity as a Service in this case) to a Client Application in order to obtain access to these APIs/URLs. See Manage OIDC and OAuth authorization.
● Client Application—The OIDC/OAuth application that provides functionality to a Resource Owner. The application can authenticate the Resource Owner using the Authorization Server (Identity as a Service) and can access APIs at the Resource Server on behalf of the Resource Owner.
● Authorization Server (Identity as a Service in this case)—The server that provides authentication to the Resource Owner and issues ID tokens, access tokens, or refresh tokens consented to by the Resource Owner for authentication and authorization purposes.
OAuth manages resource access and sharing while OIDC manages user authentication. By integrating your OIDC and OAuth application with Identity as a Service, it allows applications using desktop and mobile devices to confirm an end-user's identity based on the authentication method used by Identity as a Service and alternatively allows applications to obtain JWT access tokens used to access resource server APIs on behalf of a user.
Identity as a Service supports the Authorization Code (or Basic) Flow use case, the Implicit Flow use case, and the Client Credentials Grant use case. Refresh token are also optionally supported with the Authorization Code Flow.
Attention: The Implicit grant type has security implications. It is currently supported with OpenID Connect (OIDC) and not with OAuth. It is deprecated and will be removed in a future Identity as a Service release. Applications using the Implicit grant type should use the Authorization Code grant type with Proof Key for Code Exchange (PKCE) instead.
See the following for more information:
● See OpenID Connect Core 1.0 incorporating errata set 1 for more information on OpenID Connect and the configurations they support.
● See https://tools.ietf.org/html/rfc6749 for more information on OAuth 2.0.
● See https://tools.ietf.org/html/draft-ietf-oauth-v2-1-01 for more information on OAuth 2.1.
Identity as a Service issues the following tokens for OIDC and OAuth applications.
● ID Token—Used to authenticate to an OIDC/OAuth application. An ID Token may also contain user information, for example, profile information. The aud claim is set to the client id of OIDC and OAuth application. An ID Token is not meant for resource server APIs.
● Access Token—There are two types of access tokens:
– Access Token (Userinfo)—Used by an OIDC/OAuth application to obtain user information, for example, profile information. A Userinfo Access Token is an opaque value. A Userinfo Access Token is not meant for resource server APIs.
– Access Token (JWT)—Used by an OIDC/OAuth applications for authorization when accessing a resource server API. A JWT Access Token is a signed, self-contained, JWT. It contains the scopes (permissions) that imply what actions are allowed when the application invokes the resource server API. The aud claim is set to the resource server API value. A JWT Access Token is not meant to be parsed by an OIDC and OAuth application but rather used by it when accessing the resource server API on behalf of the user.
● Refresh Token—Used to acquire another Access Token and Refresh Token when an Access Token expires. Refresh Tokens can be issued for both a Userinfo Access Token and a JWT Access Token. A Refresh Token is an opaque value. A Refresh Token is not meant for resource server APIs.
In addition to the standard OIDC request parameters, OIDC and OAuth support the following ones:
● login_hint
● claims
● acr_values
● amr_values
● audience or resource
● org_id
OIDC and OAuth do not support the following OIDC request parameters:
● display
● id_token_hint
● ui_locales
OIDC and OAuth do not support the following features:
● Introspection
● Dynamic Client Registration
● Token Encryption
Identity as a Service supports the following OIDC and OAuth applications:
● Generic Web applications—A backend application running on a server used by a user (for example, ASP.NET and Web server application frameworks).
● Generic Single-page (SPA) application—A single page application (SPA) typically running JavaScript in a browser making Ajax-type API calls (for example, AngularJS+, Node.js, and React).
● Generic Web server (server to server)—A backend application running on a server that is used by another server-based application, without user interaction, to make API calls (for example, command line interfaces and daemon scripts). The client is the resource owner in this case.
● Device application—A client application that runs on an input-constrained or browserless device (for example, a TV set top box, a picture frame, or a printer).
● Native application—A client application that cannot communicate securely with Identity as a Service using a client secret in order to obtain various tokens. Tokens are returned directly to the Native application (possibly through an Operating System specific in-app view controller or a system browser.
IDaaS also provides a number of preconfigured templates for additional OIDC and OAuth integrations. See the Technical Integration Guides for more information.
Topics in this section:
● Integrate a generic OIDC and OAuth Cloud application
● Integrate a generic OIDC and OAuth Web application
● Integrate a generic OIDC and OAuth SPA application
● Integrate a generic OIDC and OAuth Server application
● Integrate a generic OIDC and OAuth Device application
● Integrate a generic OIDC and OAuth Native application
● View the OIDC and OAuth JWKS file
● Create and manage OIDC and OAuth signing certificates
● Manage OIDC and Auth authorization
● Manage OIDC and OAuth tokens