Skip to main content

Integrate OIDC and OAuth Cloud applications

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.

Roles​

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:

OIDC and OAuth tokens​

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.

Supported request parameters​

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

OIDC and OAuth applications​

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.
  • Embedded application—A client application that provides a custom self-hosted login interface while relying on an OpenID Connect provider to issue standards-compliant tokens.

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 generic OIDC and OAuth Device application

You can configure access to custom OpenID Connect (OIDC) device applications by integrating a generic OIDC Device application (SPA) on Identity as a Service. A device application is 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). In order to obtain authorization to access resources on the user's behalf (for example, access to movies or photos), the user authentication and authorization does not occur on the device, but rather on a separate user-controlled computer or mobile device based on a supplied URL and user code. After the user completes the authentication, the device application is able to acquire the required tokens to access the resource on the user's behalf.

📄️Integrate a generic OIDC and OAuth Native application

You can configure access to custom OpenID Connect (OIDC) applications by integrating a generic OIDC Native application with Identity as a Service. A Native application is 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).

📄️Configure an OIDC and OAuth claim

You can include Identity as a Service authenticators, groups, and organizations as part of the OIDC claim to an application during authentication. These are called User Related Attributes on Identity as a Service. For example, if a user authenticated using an OTP and Password authenticator and belonged to Group1, Group2, and Group3, and were associated with organizations MyOrganization and Beta, then the token responses can be configured to include these claims, as shown in this example: