# Incode Glossary This page defines the terms you will encounter across the Incode Platform documentation. Terms are grouped by topic. Use the alphabetical index below to jump directly to any term. *** ## Alphabetical Index [Admin Token](#admin-token) · [Age Assurance](#age-assurance) · [AML](#aml) · [API Key](#api-key) · [Authentication](#authentication) · [Authorization](#authorization) · [Biometric Template](#biometric-template) · [Capture-Only Mode](#capture-only-mode) · [Claims Match](#claims-match) · [Client ID](#client-id) · [Condition Node](#condition-node) · [Configuration ID](#configuration-id) · [Crosscheck](#crosscheck) · [Custom Fields](#custom-fields) · [Customer UUID](#customer-uuid) · [Dashboard](#dashboard) · [Device and Behavior Risk Check](#device-and-behavior-risk-check) · [Deepsight](#deepsight) · [Digital ID Verification](#digital-id-verification) · [Document Verification](#document-verification) · [eKYB](#ekyb) · [eKYC](#ekyc) · [Email Risk Check](#email-risk-check) · [EXIF](#exif) · [External Customer ID](#external-customer-id) · [External ID](#external-id) · [E2EE Mode](#e2ee-mode) · [Face Authentication](#face-authentication) · [Face Match](#face-match) · [Flow](#flow) · [Government Validation](#government-validation) · [IAM](#iam) · [Identity Provider (IdP)](#identity-provider-idp) · [Images](#images) · [Incode Identity](#incode-identity) · [interviewId](#interviewid) · [KYB](#kyb) · [KYC](#kyc) · [Liveness Detection](#liveness-detection) · [Manual Review](#manual-review) · [Module](#module) · [Module Node](#module-node) · [MRZ](#mrz) · [NFC Scan](#nfc-scan) · [OCR](#ocr) · [OIDC](#oidc) · [Omni API](#omni-api) · [Onboarding Attempts](#onboarding-attempts) · [Onboarding Session](#onboarding-session) · [PEP](#pep) · [Phone Risk Check](#phone-risk-check) · [Prizma](#prizma) · [Process Node](#process-node) · [Proof of Address](#proof-of-address) · [Queue](#queue) · [Result Node](#result-node) · [Rules Engine](#rules-engine) · [Score](#score) · [Silent Network Authentication (SNA)](#silent-network-authentication-sna) · [SDK](#sdk) · [Session Status](#session-status) · [Session Token](#session-token) · [UBO](#ubo) · [Video Selfie](#video-selfie) · [Watchlist](#watchlist) · [Webflow](#webflow) · [Webhook](#webhook) · [Workflow](#workflow) · [1:1 Face Authentication](#11-face-authentication) · [1:N Face Authentication](#1n-face-authentication) *** ## Sessions and Identifiers ### Onboarding Session A container for one user's identity verification process. Every image, document, selfie, score, and event produced during verification is attached to the session. A new session must be created for each verification attempt, even if the same person is attempting again. _Also called:_ interview, session. → [Onboarding Session Lifecycle](onboarding-session-lifecycle) *** ### interviewId The unique identifier for an Onboarding Session. It is an alphanumeric string assigned by the Incode platform when a session starts. Every API call that reads or writes data for a specific session uses the `interviewId` to identify it. `interviewId` is the term used in code and API parameters. In Dashboard, the same identifier is called the **Session ID**. Both refer to the same value. *** ### Onboarding Attempts Each time a user goes through the onboarding process, that attempt creates a new Onboarding Session with a unique Session ID (interviewId), regardless of whether the user completed or abandoned the process. Key behaviors include: - Users can make multiple attempts using the same or different Workflow or Flow. - Each attempt has its own score, so the same person may have a different result for each attempt. - Multiple attempts by the same person can be linked using a shared externalCustomerId. *** ### Session Token A short-lived credential returned when a session is created. The session token is passed to the SDK so the front end can interact with Incode's API on behalf of that specific session. It is separate from the API key, which identifies your organization. The session token identifies one user's session. Do not expose your API key on the front end. Use the session token on the front end and keep the API key on your back end. → [How to get an access token](https://developer.incode.com/reference/how-to-get-an-session-token) *** ### Admin Token A credential used by your back end to call Incode API endpoints that require elevated access, such as fetching session results or verifying a face authentication attempt. The admin token is never sent to the front end. → [How to get an access token](https://developer.incode.com/reference/how-to-get-an-session-token) *** ### API Key A credential that identifies your organization to the Incode platform. It is included as the `x-api-key` header in every API request from your back end. Treat your API key as a secret — do not include it in front-end code or expose it in client-side logs. → [Request Header](https://developer.incode.com/reference/how-to-get-an-session-token#request-header) *** ### Configuration ID The identifier for a Flow or Workflow configuration as defined in the Omni Dashboard. Also called a **flow ID**. When you initialize an SDK session or start a session via the API, you pass the Configuration ID to tell the platform which set of modules and settings to use for that session. *** ### External Customer ID A string you define in your own system, such as a user ID or account number, that links an Incode Onboarding Session to a record in your database. It is stored in the session and returned in API responses and webhook payloads so you can match Incode results back to your users. Multiple onboarding attempts by the same person can be linked via the same `externalCustomerId`. *** ### External ID Similar to External Customer ID, but with different resumption behavior. If a session already exists for a given `externalId`, submitting the same value resumes that session instead of creating a new one. Use this when you want to prevent duplicate sessions for the same user. *** ### Custom Fields Key-value pairs that allow you to attach additional metadata to an Onboarding Session. Custom Fields are flexible tags you define that can be retrieved later via the API. They are useful for advanced session filtering, analytics, and integrations with external systems. *** ### Customer UUID A unique identifier assigned to a verified user when their Incode Identity is created after a successful onboarding. It represents the person's biometric identity in the Incode platform and is required for 1:1 face authentication on return visits. *** ### Session Status The current state of an Onboarding Session. Statuses are set by the platform as modules complete. Key statuses include: - `UNKNOWN`: Session created but no data collected yet - `ID_VALIDATION_FINISHED`: ID document processing is complete - `FACE_VALIDATION_FINISHED`: Selfie and face match processing is complete - `GOVERNMENT_VALIDATION_FINISHED`: Government database check is complete - `ONBOARDING_FINISHED`: All modules have run and the session is complete - `APPROVED`: Session score met the threshold and the user was approved - `MANUAL_REVIEW`: Session was flagged for human review - `MANUAL_REVIEW_APPROVED`: A reviewer approved the session - `MANUAL_REVIEW_REJECTED`: A reviewer rejected the session → [Onboarding Session Lifecycle](onboarding-session-lifecycle) *** ## Flows, Workflows, and Modules ### Flow A legacy configuration method for defining the steps of an Onboarding Session. Flows are configured in Dashboard and referenced by a Configuration ID. New integrations should use **Workflows** instead. Flows remain supported but are no longer the recommended approach. → [Flows](flows-1) *** ### Workflow The current, recommended way to configure an Onboarding Session. A Workflow is built in Dashboard using a visual drag-and-drop builder. It defines which verification modules run, in what order, and what logic determines the outcome. Workflows support conditional branching, meaning different users can follow different paths based on their data or scores. → [Workflows Overview](workflows) *** ### Module A single step in an Onboarding Session. Each module handles one task: for example, capturing an ID document, taking a selfie, or running an eKYC check. Modules are selected and configured when building a Flow or Workflow. Some modules collect data from the user (capture modules), and some process or validate data that was already collected (process modules). _Also called:_ Verification Module. → [Modules Overview and Availability](https://developer.incode.com/docs/modules-overview-and-availability) *** ### Module Node In the Workflow builder, a Module Node represents a step that involves the customer, such as ID capture, selfie capture, or consent. Module nodes are the interactive steps a user sees and acts on during an Onboarding Session. → [Create Workflows](https://developer.incode.com/docs/workflows-20#create-workflows) *** ### Process Node In the Workflow builder, a Process Node runs automatically without customer interaction. It processes or validates data collected by a preceding module: for example, running a face match after a selfie is captured, or performing an eKYC check after ID data is extracted. Process Nodes must follow the relevant Module Nodes in the workflow. → [Create Workflows](https://developer.incode.com/docs/workflows-20#create-workflows) *** ### Condition Node In the Workflow builder, a Condition Node branches the customer journey based on data or scores. For example, a condition can route a customer to manual review if their ID score is below a threshold or skip a step if a previous check already passed. Conditions use AND/OR logic and can evaluate scores, module results, or custom field values. → [Conditions for Workflows](conditionals-use-cases) *** ### Result Node In the Workflow builder, a Result Node ends a branch of the customer journey. Every branch in a Workflow must end with a Result Node. The Result Node sets the final outcome of the session for that path: `OK`, `FAIL`, `MANUAL`, or `WARN`. → [Create Workflows](https://developer.incode.com/docs/workflows-20#create-workflows) *** ### Webflow A hosted web application created in Dashboard that runs a complete Onboarding Session. Users access it via a URL; no SDK integration is required. Webflows are the no-code option for deploying identity verification. _Also called:_ Hosted Flow, Onboarding URL. *** ### Rules Engine A configuration tool in Dashboard that lets you define automatic decision logic for sessions using Flows. Rules evaluate scores and module results to determine whether a session is approved, denied, or sent to manual review without requiring custom back-end code. → [Flows](flows-1) *** ### Crosscheck A comparison step that checks whether a specific piece of data from one source matches the same data from another source within the same session. For example, a crosscheck can compare the name extracted from an ID document against the name on a utility bill submitted as proof of address. Crosschecks are configured in Dashboard and run as Process Nodes in a Workflow. → [Fetching Crosscheck Results](fetching-crosscheck-results) *** ## Scores and Decisions ### Score A numerical value that represents how confident the platform is in the result of a verification step. Each module produces its own score, and the platform calculates an overall session score based on the modules configured as validation modules. Your back end uses scores to approve, reject, or flag sessions for manual review. Score thresholds are configured per Flow or Workflow in Dashboard. *** ### Manual Review A state in which a session is held for a human reviewer to examine before a final decision is made. A session enters Manual Review when its score falls in a range defined as requiring human judgment, typically between the automatic-approve and automatic-reject thresholds. Reviewers access flagged sessions through Dashboard. *** ### Queue A named group to which sessions are assigned when they require manual review. Queues allow organizations to route sessions to specific reviewer teams: for example, by region, product line, or risk level. Queues are configured in Dashboard and can be specified per session when using the Video Conference module. *** ## Verification Capabilities ### Authentication Authentication is the process of confirming that users are who they say they are. It serves as the initial step in a security procedure. → [Onboarding or Authentication: When to Use Each](https://developer.incode.com/docs/onboarding-vs-authentication) *** ### Authorization The process of granting a user permission to access a particular resource or perform a specific function. Authorization is often used interchangeably with access control or client privileges, but it is distinct from authentication: authentication verifies who a user is, while authorization decides what they are allowed to do. Incode does not provide an authorization layer. Incode returns a result, and your application decides what action to take. *** ### Liveness Detection A check that confirms a selfie was captured from a live person rather than from a photo, video, or synthetic image. The Incode platform supports both: - **Passive liveness**: No user action required. - **Active liveness**: The user is prompted to perform an action. Incode's liveness detection is certified to ISO/IEC 30107-3. Liveness detection within Incode's Deepsight suite is divided into three sub-checks: - **Physical Check**: Masks, printed photos - **Digital Check**: Screen replay, injected video - **Evasion Check**: Attempts to bypass detection → [Deepsight](https://developer.incode.com/docs/deepsight) *** ### Face Match A comparison between the selfie captured during an Onboarding Session and the photo on the ID document submitted in the same session. A passing face match confirms that the person holding the ID is the same person shown in the document. Face match is a process step that runs after both an ID capture and a selfie capture are complete. *** ### Face Authentication A post-onboarding capability that lets a previously verified user prove their identity using a selfie. Incode face authentication verifies identity, confirms that users are real, and detects common fraudulent behavior through liveness checks, physical and digital attack detection, image quality checks, and face checks such as lenses, hats, closed eyes, and face masks. Two modes are available: [1:1 (one-to-one)](#11-face-authentication) and [1:N (one-to-many)](#1n-face-authentication). → [Face Authentication](https://developer.incode.com/docs/face-authentication-module) → [Onboarding or Authentication: When to Use Each](https://developer.incode.com/docs/onboarding-vs-authentication) *** ### 1:1 Face Authentication In one-to-one face authentication, the user provides a selfie and an Authentication Hint—typically their customer UUID—to claim a specific identity. The platform compares the selfie's biometric template against the biometric template stored in that enrolled identity. *** ### 1:N Face Authentication In one-to-many face authentication, the user provides only a selfie. The platform compares the selfie's biometric template against all enrolled identities in the database and identifies the closest match, without requiring the user to claim an identity first. This capability is unique to Incode among major identity verification platforms. *** ### Incode Identity A record created in the Incode platform when a user successfully completes an Onboarding Session and is approved. It stores the user's biometric template, extracted from their selfie, and is identified by a Customer UUID. An Incode Identity is required for face authentication on return visits. If any module in the onboarding fails and the session is not approved, an Incode Identity is not created. *** ### Biometric Template A mathematical representation of a person's facial features, generated from their selfie during onboarding. The template is used for face authentication; it is compared against a new selfie to confirm identity. The template itself is not a photograph; it cannot be reverse engineered into an image. *** ### OCR Optical Character Recognition (OCR) is the process of extracting text from an image. During an Onboarding Session, Incode uses OCR to read the data printed on an ID document and return it as structured data in the API response. The data extracted depends on the document type: a two-sided document such as a driver's license yields different fields than a one-sided document such as a passport. *** ### Document Verification The automated process of confirming that a government-issued identity document—such as a passport, driver's license, or national ID—is genuine, unaltered, and has not been previously used to commit fraud. Incode uses more than 35 in-house ML models to analyze ID images in real time. Document validation is available for over 10,000 document types and 200 countries and regions. Document verification detects: - Tampered photos and data fields - Counterfeit or non-compliant document formats - Reused or duplicated documents across sessions *** ### Digital ID Verification The automated process of accepting and validating digital identification documents, such as IDs stored in mobile wallets or issued through digital identity systems. Digital ID verification detects available digital IDs on a user's device, validates their authenticity and integrity via cryptographic checks, and automatically routes users to physical document verification when a digital ID is unavailable. *** ### Images Three main types of images may be captured and linked to an Onboarding Session: - Front and back images of an ID document (back image applies to two-sided documents such as driver's licenses). - Selfie images. - Images of supplementary documents, such as proof of address. A session may contain more than one image of the same type if a user needs to perform a recapture for any reason. *** ### EXIF Exchangeable Image File Format (EXIF) metadata is information automatically embedded in an image file by the device that captured it. It travels with the image and usually includes: - When the photo was taken (timestamp) - What device took it (camera make, model) - How it was taken (shutter speed, aperture, focal length, flash) - Where it was taken (GPS coordinates, if location was enabled) *** ### MRZ The Machine-Readable Zone (MRZ) is the two or three lines of text at the bottom of a passport or ID card that encode the document's key data in a standardized format. Incode reads and validates MRZ data as part of document verification. *** ### NFC Scan Near Field Communication (NFC) scan is a method of reading the embedded chip in an ePassport or chip-enabled ID card. NFC scanning retrieves digitally signed data directly from the chip, providing a higher level of document authenticity assurance than optical scanning alone. Available in the iOS, Android, and Flutter SDKs. *** ### Government Validation A verification step that checks identity data extracted from an ID document against an authoritative government database or registry. This confirms that the identity exists in the official record and matches the data on the document. Incode has direct integrations with government sources in Mexico (RENAPO, CURP, INE, SAT), Brazil, Argentina, Colombia, Chile, Peru, South Africa, Australia, and more. → [System-of-Records Documentation](https://developer.incode.com/docs/government-verification-sources) *** ### eKYC Electronic Know Your Customer (eKYC) is a non-document identity check that cross-references a user's data against trusted external data sources—such as credit bureau records, phone number registries, or email risk databases—to confirm the identity exists and is in good standing. eKYC checks supplement document and biometric verification and are commonly required for financial services compliance. → [eKYC Module](https://developer.incode.com/docs/ekyc) *** ### eKYB Electronic Know Your Business (eKYB) is a verification check that confirms a business entity is real, legally registered, and not subject to sanctions. eKYB can verify the business name, tax ID, registration status, address, and, where required, the identities of its Ultimate Beneficial Owners (UBOs). Incode supports eKYB in 15+ countries. → [eKYB Module](https://developer.incode.com/docs/ekyb) *** ### Email Risk Check An eKYC signal that evaluates the fraud risk of an email address a user submitted during sign-up or login. It analyzes indicators such as email age, reputation, usage patterns, spam signals, and watchlist status to produce a risk score. You can configure that risk score against low, medium, high, or custom thresholds to inform downstream decisioning. Email Risk Check detects: - Disposable, temporary, or undeliverable email addresses - Compromised or breach-exposed accounts - Suspicious usage patterns associated with fraud *** ### Phone Risk Check An eKYC signal that evaluates the fraud risk of a phone number a user submitted. It uses carrier data, number type, and historical usage to determine the phone number's validity, activity status, VOIP or prepaid classification, and leak exposure. It also determines a risk level (low, medium, high, or very high) to inform decisioning. Phone Risk Check detects: - Recycled, virtual (VoIP), or prepaid numbers commonly linked to fraud - Inactive, improperly formatted, or undeliverable numbers - Numbers with known spammer associations *** ### Device and Behavior Risk Check A passive fraud detection layer that analyzes the user's device environment and behavioral patterns throughout the verification session. Device intelligence covers attributes such as IP address, geolocation, OS/browser configuration, and network anomalies. Behavioral signals capture interaction patterns such as typing cadence, touch dynamics, and navigation flow. Together, they detect bots, account takeovers, and synthetic behavior in real time, triggering step-up verification only when risk is high. Device and Behavior Risk Check detects: - Device spoofing, emulation, proxy use, and network anomalies - Bot-like or scripted interaction patterns - Session behavior consistent with account takeover or synthetic identity fraud *** ### UBO The Ultimate Beneficial Owner (UBO) is the individual who ultimately owns or controls a business entity, typically defined as owning 25% or more of the company. Many KYB regulations require businesses to identify and verify their UBOs as part of onboarding. *** ### Proof of Address A document—such as a utility bill, bank statement, or government letter—that confirms a user's residential address. Incode can capture and process proof of address documents as a module in an Onboarding Session, including OCR extraction of the address and crosscheck comparison against the address on the user's ID. *** ### Watchlist A list of individuals or entities against which a user's identity is screened. The Incode platform supports three types: - **Global Watchlist**: Screens against international sanctions lists, Politically Exposed Persons (PEP) databases, and other regulatory watchlists. - **Custom Watchlist**: A list you manage in Dashboard. Can be configured as a Blocklist (deny matches) or an Allowlist (approve matches). - **Watchlist for Business**: A list that works together with eKYB. → [Watchlists](https://developer.incode.com/docs/business-watchlist) *** ### PEP A Politically Exposed Person (PEP) is an individual who holds or has held a prominent public position, such as a government official, senior executive of a state-owned company, or senior military officer. Regulatory frameworks require organizations to apply enhanced due diligence when onboarding PEPs. Incode's Global Watchlist module screens for PEPs as part of Anti-Money Laundering (AML) compliance. *** ### Age Assurance A module that estimates a user's age from their selfie using AI, without requiring a government ID. Age Assurance is used in regulated contexts where a platform needs to confirm a user meets a minimum age requirement. It is distinct from age verification via ID document. When Age Assurance is enabled, session recording options for ID Capture and Face Capture are restricted. Deepsight recordings are deleted on session completion. Age Assurance requires additional licensing. Contact your Incode Representative. *** ### Video Selfie A module that records a short video of the customer responding to voice-prompted questions. The video serves as a high-assurance liveness check and produces a video artifact for compliance and audit purposes. This module is unique to Incode: no other major IDV platform in this space offers a voice-prompted video selfie with a recorded Q\&A format. *** ### Silent Network Authentication (SNA) Silent Network Authentication is a carrier-based phone verification method that confirms a user's possession of a mobile number directly through the mobile network. Instead of relying on one-time passwords (OTP), SNA runs silently in the background. This eliminates user friction and protects against phishing, SIM swaps, and interception attacks. When SNA isn't available for a given number or carrier, flows automatically fall back to SMS OTP. See [Silent Network Authentication](https://developer.incode.com/docs/silent-network-authentication) for full details. *** ### Claims Match A step that cross-checks verified identity attributes—such as name, date of birth, phone number, or email—from an Incode session against records in an external directory, such as an identity and access management (IAM) system or HR database. Claims match is used to confirm that the person being verified matches a known record in your organization. It is available in Workforce integrations. *** ### Deepsight Incode's dedicated deepfake and fraud defense suite. Deepsight evaluates the authenticity of a selfie capture across multiple dimensions: - **Physical Check**: Detects physical spoofs such as printed photos, masks, and mannequins. - **Digital Check**: Detects digital attacks such as screen replay and injected video feeds. - **Evasion Check**: Detects attempts to bypass the liveness check system. - **Behavioral Trust**: Evaluates device and interaction behavior for anomalies. - **Device Trust**: Assesses the trustworthiness of the device being used. Deepsight also produces a Media Manipulation Index (MMI) score for document images, indicating whether a document image shows signs of digital manipulation. Deepsight requires additional licensing. Contact your Incode Representative. → [Deepsight](https://developer.incode.com/docs/deepsight) *** ## Platform Components ### Dashboard The web-based administration application for the Incode Platform. Used to configure Flows and Workflows, review session results, manage users and roles, set up webhooks, and access analytics. Both developers and operations teams use Dashboard. *** ### Omni API The REST API that powers the Incode platform. Your back end uses the Omni API to create sessions, submit verification data, retrieve scores and OCR results, and trigger platform actions. All API requests require an API key header (`x-api-key`) and most session-level requests also require a session token or admin token. → [API Reference](https://developer.incode.com/reference) *** ### SDK The software development kit (SDK) is a library that handles the capture UI, camera management, and API communication for an Incode integration. Incode provides SDKs for Web, iOS, Android, React Native, Flutter, Xamarin, Cordova, and Ionic Capacitor. Using an SDK is the recommended integration approach for most use cases. It handles image quality optimization, device compatibility, and data submission automatically. → [SDK Reference](https://developer.incode.com/docs/sdk-reference) *** ### Prizma Incode's design system for user interfaces. Prizma provides a documented set of design tokens, component specifications, and customization guidelines that allow you to match the verification UI to your product's visual identity. It supports light and dark mode and includes V1 and V2 component comparisons. No other major IDV platform publishes a design system at this level of detail. → [Prizma Design System](https://developer.incode.com/docs/prizma-design-foundations) *** ### Capture-Only Mode An SDK integration mode for iOS and Android SDKs that separates the capture layer from the processing layer. In Capture-Only mode, the Incode SDK handles camera access and image quality optimization, but the captured data is sent to your own back end rather than directly to Incode's processing servers. Useful for privacy-constrained architectures or hybrid setups. *** ### E2EE Mode End-to-end encryption (E2EE) mode is an integration variant for iOS and Android SDKs in which all captured data is cryptographically encrypted on the device before transmission to Incode's servers. Useful for high-assurance deployments with strict data security requirements. No other major IDV platform publicly documents an E2EE integration mode. *** ### Webhook An HTTP callback that the Incode platform sends to your back end when a session event occurs: for example, when a session status changes, a module completes, or a video selfie is uploaded. Webhooks let your back end react to verification events without polling the API. Webhook requests can be authenticated using an OAuth 2.0 bearer token. → [Webhooks](https://developer.incode.com/docs/webhooks-overview) *** ## Compliance and Regulatory Terms ### KYC Know Your Customer (KYC) is a regulatory requirement that obligates financial institutions and other regulated organizations to verify the identity of their customers before and during a business relationship. KYC is a core driver for identity verification in banking, fintech, insurance, and other regulated industries. *** ### KYB Know Your Business (KYB) is the business-entity equivalent of KYC. Organizations in regulated industries must verify that businesses they onboard are legitimate, legally registered, and not subject to sanctions. They must also identify the individuals who own or control them. *** ### AML Anti-Money Laundering (AML) is a set of laws, regulations, and procedures that require financial institutions to detect and prevent money laundering. KYC and watchlist screening are both components of AML compliance. Incode's platform supports AML workflows through global watchlist screening, eKYC checks, and sanctions screening. *** ### IAM Identity and access management (IAM) is a framework for controlling who can access what resources in an organization. In the context of Incode's platform, IAM integration refers to connecting Incode's identity verification capabilities with IAM systems such as Okta or Microsoft Entra, so that verification results can drive access decisions. *** ### Identity Provider (IdP) A system that authenticates users and provides identity assertions to other applications. Incode can act as an Identity Provider using the OpenID Connect (OIDC) protocol, allowing other applications to accept Incode's biometric authentication as a login method. *** ### OIDC OpenID Connect (OIDC) is an authentication protocol built on top of OAuth 2.0. It allows applications to verify the identity of a user based on authentication performed by an Identity Provider. Incode supports OIDC for both consumer-facing authentication flows and workforce integrations with systems like Okta and Microsoft Entra. → [OIDC Automatic Configuration](https://developer.incode.com/docs/oidc-automatic-configuration) → [OIDC Manual Configuration](https://developer.incode.com/docs/oidc-manual-configuration) *** ### Client ID In the context of OIDC integrations, a client ID is the identifier assigned to your application when it is registered with Incode as an Identity Provider. It is included in OIDC authentication requests to identify which application is requesting authentication.