- Verify
- How it works
- Using OpenID Connect
How it works
Using OpenID Connect
Learn how Idura Verify implements the OpenID Connect protocol and find the right authentication flow for your tech stack.
Idura Verify acts as an OpenID Provider (Authorization Server). You integrate with our authentication API using standard OpenID Connect (OIDC) and OAuth 2.0 specifications.
Supported authentication flows
OpenID Connect defines different strategies (flows) to authenticate users. Idura Verify supports five different flows. Use the guide below to determine which OIDC flow fits your application architecture.
You don't need to implement authentication flows from scratch. An OpenID Connect client library or one of Idura's SDKs will handle implementation for you.
- Idura SDKs: We provide SDKs for popular frameworks like React, Node.js, and ASP.NET. Explore our SDKs and integration guides.
- Standard OIDC libraries: If you can't find an Idura SDK for your stack, you can use any standard OpenID Connect library for your platform. Popular examples include Authlib (Python), Spring Security (Java), and go-oidc (Go).
Authorization Code flow
Intended for: Traditional server-side web applications (e.g., ASP.NET, Node.js/Express, PHP).
How it works: Server-side web applications (confidential clients) can securely store a client secret and establish back-channel communication with Idura Verify. This facilitates a secure code-for-token exchange during authentication. (Note: While this flow is fully supported, upgrading to PKCE is recommended).
Authorization Code flow implementation details
PKCE flow
Intended for: Single-page applications, native mobile apps (iOS/Android), and traditional server-side web applications.
How it works: PKCE (Proof Key for Code Exchange, pronounced pixy) is an extension to the standard Authorization Code flow. It requires your app to dynamically generate a unique, one-time cryptographic secret for every login request, then use it during the code exchange. While originally designed for public clients that cannot securely store a client secret, the industry best practices now recommend PKCE for all applications due to its enhanced security features.
PKCE flow implementation details
CIBA flow
Intended for: Call centers or point-of-sale terminals.
How it works: Client-Initiated Backchannel Authentication (CIBA) is a decoupled flow, meaning the device initiating the login is different from the device where the user actually authenticates. An agent initiates the login from their terminal, and Idura Verify sends a push notification directly to the user's smartphone (e.g., via the Swedish BankID or Norwegian BankID app) asking them to approve the request. No browser redirects are involved.
CIBA flow implementation details
Headless flow
Intended for: Use cases not covered by other OpenID Connect flows, such as rendering UI elements in your own webpage instead of via an Idura redirect, or performing app2app without a browser.
How it works: The Headless flow is a custom protocol provided by Idura. It allows interacting with eIDs that offer a poll-based workflow, where a user agent redirect is not required.
Headless flow implementation details
Implicit flow (legacy)
Intended for: Debugging only.
How it works: The Implicit flow returns the ID token directly in the browser's URL fragment. Support for this flow is being discontinued as it does not satisfy modern security standards. It remains available for use in test domains for simpler debugging during development.