Concepts and architecture · Authorization Identity Protocols

Authorization and Identity Protocols

Incode supports identity verification as part of an OpenID Connect (OIDC) authentication flow. This page explains how OAuth 2.0 and OIDC work together and describes the two ways to configure OIDC in Dashboard.


OAuth 2.0 and OpenID Connect

OAuth 2.0 and OpenID Connect (OIDC) are related but distinct protocols. They are often used together.

  • OAuth 2.0 is an authorization framework. It controls access to resources. When a user authorizes your application, the authorization server issues an access token. Your application uses that token to make API requests on the user's behalf.
  • OpenID Connect (OIDC) is an authentication layer built on top of OAuth 2.0. It confirms the user's identity. In addition to an access token, the authorization server issues an ID token. The ID token confirms who the user is. It is a JSON Web Token (JWT) signed by the authorization server, and your application must validate it before trusting its contents.

Together, they work like this:

  1. Your application redirects the user to the authorization server.
  2. The user authenticates by completing a Flow or Workflow.
  3. The authorization server issues an authorization code.
  4. Your application exchanges the code for an access token and an ID token.
  5. Your application validates the ID token and uses the access token to call Incode APIs.

Incode uses the authorization code flow with Proof Key for Code Exchange (PKCE). This is the recommended flow for web and mobile applications.


Configuration Methods

Incode supports two ways to configure OIDC: automatic and manual. The right choice depends on how your integration is structured.

Automatic Configuration

Automatic configuration ties OIDC directly to a specific Flow or Workflow. When you enable the OAuth2 Secured flag on a Flow or Workflow, Incode automatically generates a dedicated OIDC client for it. You do not need to create or manage the client manually. This client is configured as a public client using PKCE. A client secret is generated but never surfaced or used, since authentication relies only on the PKCE code and verifier.

Use automatic configuration when:

  • You want OIDC authentication scoped to a specific Flow or Workflow.
  • You want Incode to manage client generation for you.
  • You are building a new integration.

For setup instructions, see OIDC Automatic Configuration.

Manual Configuration

Manual configuration lets you create and manage OIDC clients directly in Dashboard in Configuration > Authorization. You define the client ID, client secret, redirect URIs, authentication methods, and grant types yourself.

Scoping under manual configuration depends on the authentication type. For example, onboarding authentication is scoped to a specific Flow or Workflow, while face authentication is not tied to a Flow or Workflow.

Use manual configuration when:

  • You need a standalone OIDC client whose scoping doesn't fit the automatic model
  • You require specific authentication methods or grant types not available through automatic configuration.
  • You are managing an existing integration.

For setup instructions, see OIDC Manual Configuration.

Comparison

OIDC Automatic Configuration OIDC Manual Configuration
Incode generates an OIDC client You create a OIDC client in Dashboard
Scoped to a Flow or Workflow Scoping depends on authentication type
Configured as a public client using PKCE; no client secret is used You manage the client secret
Recommended for new integrations Recommended for existing integrations

Was this page helpful?