🔐 What is OIDC and How It Works

OpenID Connect (OIDC) is an identity layer built on top of OAuth 2.0, designed to provide authentication and user identity verification. While OAuth 2.0 primarily focuses on authorization—granting applications permission to access resources—OIDC extends this framework by enabling applications to authenticate users in a standardized and secure manner.

OIDC allows applications to verify user identities by obtaining an ID token from an identity provider (IdP). This ID token contains structured claims about the authenticated user, such as their unique identifier, email, and authentication method. This process eliminates the need for applications to handle user credentials directly, enhancing security and usability.

Core Components of OIDC

1. ID Token

An ID token is a JWT (JSON Web Token) that includes user identity claims. Key fields within the ID token include:

Issuer (iss): Identifies the IdP that issued the token.
Subject (sub): Represents the unique identifier for the authenticated user.
Audience (aud): Specifies the intended recipient of the token (e.g., the application).
Expiration (exp): Defines when the token expires.
Authentication Timestamp (auth_time): Records when the user was authenticated.

The ID token allows applications to verify a user’s identity without requiring direct credential handling.

2. Access Token

The access token in OIDC serves the same purpose as in OAuth 2.0: it authorizes API access. Unlike the ID token, the access token does not contain identity claims but grants permissions to interact with secured resources.

3. Endpoints in OIDC

OIDC introduces several standard endpoints that facilitate authentication and identity management:

Authorization Endpoint: Handles user authentication and authorization requests.
Token Endpoint: Exchanges authorization codes for tokens (ID token, access token).
UserInfo Endpoint: Allows applications to retrieve additional user attributes (e.g., name, email) after authentication.
Discovery Endpoint: Provides metadata about the identity provider, including supported authentication flows and endpoints.

Benefits of Using OIDC

Standardized Authentication: OIDC provides a consistent and secure method for user authentication across different applications.
Enhanced Security: By replacing passwords with tokens, OIDC reduces the risk of credential exposure.
Scalability: Supports federated identity management and single sign-on (SSO), enabling seamless authentication experiences.
Interoperability: Compatible with major identity providers like Google, Microsoft, and Okta, making integration easier for developers.

By implementing OIDC, applications can enhance user authentication security while improving user experience. The following sections will delve deeper into implementing OIDC authentication and securing identity management in practice.

The OIDC authentication process typically follows these steps:

User Authentication: The user logs in via an identity provider (IdP) such as Google, Microsoft, or a custom authentication system.
Authorization Request: The application requests authentication and identity information from the IdP.
Token Issuance: If authentication is successful, the IdP issues an ID token (along with an access token, if required).
Token Validation: The application verifies the ID token’s integrity using the IdP’s public keys.
Identity-Based Access Control: Based on the extracted claims, the application grants or denies access to resources.

Real-World Scenarios: How OIDC Works in Practice

To better understand how the OIDC authentication process is applied in the real world, let’s walk through two distinct use cases, each demonstrating how the steps play out in a meaningful context.

Use Case 1: Logging into a Web App with Google (B2C)

Scenario A user wants to log into a web-based note-taking application (like Evernote or Notion) by clicking “Log in with Google.”

Step-by-Step Breakdown

User Authentication
- The user is redirected to Google’s login page.
- After entering credentials and completing multi-factor authentication (if required), Google verifies the user.
- 👉 Significance: Authentication is delegated to a trusted provider (Google), reducing risk for the application.
Authorization Request
- The app sends an authorization request to Google with parameters such as:
  - client_id, redirect_uri, response_type=code
  - scope=openid profile email
- 👉 Significance: The app requests permission to retrieve the user’s identity information.
Token Issuance
- Upon successful login, Google redirects the user back to the app with an authorization code.
- The app exchanges the code for:
  - ID Token – identity data (e.g., email, sub)
  - Access Token – optional, to access Google APIs
- 👉 Significance: The ID Token proves who the user is; the Access Token allows access to other APIs.
Token Validation
- The app validates the ID Token by checking:
  - Its signature using Google’s public keys
  - iss, aud, and exp claims
- 👉 Significance: Ensures the token is authentic and hasn't expired.

Use Case 2: Employee Logging into an Internal Dashboard (B2E)

Scenario An employee accesses an internal enterprise application using their company login via Azure Active Directory (Azure AD).

Step-by-Step Breakdown

User Authentication
- The employee clicks “Sign in” and is redirected to Azure AD.
- They log in with corporate credentials and complete MFA.
- 👉 Significance: Centralized enterprise identity ensures strong security and governance.
Authorization Request
- The app requests authorization with scopes such as openid profile email roles.
- 👉 Significance: The app requests identity and role-based information for fine-grained access control.
Token Issuance
- Azure AD returns an authorization code.
- The app exchanges it for:
  - ID Token – includes user ID, department, and roles
  - Access Token – for accessing protected company APIs
  - Refresh Token – optional, to extend the session
- 👉 Significance: Tokens deliver both identity and access capabilities securely.
Token Validation
- The app validates the ID Token and Access Token.
- It uses claims like roles to determine what resources the user can access.
- 👉 Significance: Enforces Role-Based Access Control (RBAC).

📘 Summary: Meaning Behind Each Step

Step	Description	Significance
1. User Authentication	User logs in via the IdP	Entry point for secure identity verification
2. Authorization Reques	App requests access and identity information	Explicit consent and scope-limited data sharing
3. Token Issuance	IdP issues tokens after verifying the user	Secure delivery of identity and access credentials
4. Token Validation	App verifies the tokens before granting access	Prevents misuse and ensures trusted user sessions

Expand Your Understanding

For those interested in diving deeper into OIDC, here are some excellent resources:

OpenID Connect Core 1.0 Specification – The official spec
OAuth 2.0 and OpenID Connect Explained (Auth0 Docs) – Beginner-friendly guide
Introduction to OpenID Connect (Okta Developer Blog) – Covers practical applications
JWT.io – Tool for inspecting and understanding JWTs used in OIDC

Differences Between OAuth 2.0 and OIDC

Although OIDC and OAuth 2.0 are closely related, they serve different purposes:

Feature	OAuth 2.0	OpenID Connect (OIDC)
Primary Function	Authorization	Authentication & Identity Verification
Token Type	Access Token	ID Token & Access Token
User Involvement	Optional (depends on grant type)	Requires user authentication
Use Case	API access control	User authentication and login management
Scopes	Defines API permissions	Adds openid, profile, email scopes for identity claims

OIDC is particularly beneficial for applications that require user authentication, whereas OAuth 2.0 alone is sufficient for API authorization.

🛠️ Setting Up OIDC Login in digiRunner

Setting up OpenID Connect (OIDC) for authentication in digiRunner enhances security and simplifies user management. It allows users to log in to the Admin Console using their existing identity provider (IdP), such as Google, Azure AD, or other OIDC-compliant services.

🔗 Reference Guide: Connecting OIDC Account and Logging in Admin Console

Steps to Implement OIDC Login in digiRunner

This section outlines the steps to implement OpenID Connect (OIDC) login functionality in digiRunner. By following these steps, organizations can integrate secure, standards-based authentication into their API management workflows. For more details, refer to the digiRunner Documentation Center.

📘 Reference: Connecting OIDC Account and Logging in Admin Console

1. Configure an OIDC Identity Provider (IdP)

Log in to the digiRunner Admin Console, and go to Client Management → GTW OAuth 2.0 IdP.
Click Add, and configure the following fields:
- Client ID
- Client Secret
- Authorization Endpoint
- Token Endpoint
- User Info Endpoint
Save the settings.

2. Link the OIDC Provider to an API Client

Navigate to Client Management → API Client.
Select or create an API Client.
In the client settings, associate it with the previously configured GTW OAuth 2.0 IdP.

3. Configure API Scope and Access Control

Define API Scopes to manage different levels of access.
Assign the scopes to the appropriate API Clients to enforce access control policies.

4. Enable OIDC Login for the Admin Console

Ensure that the Admin Console is configured to support OIDC-based login.
Navigate to System Settings → Login Settings, and select the OIDC Identity Provider you set up.

5. Test the OIDC Login Flow

On the login page of the Admin Console, choose to log in using the OIDC Provider.
Verify that authentication is successful and that user permissions are applied correctly.

By following these steps, your organization can successfully implement OIDC authentication in digiRunner, enhancing both security and user convenience. 🚀

Setting Up OIDC in API Management

In digiRunner, you can enable OpenID Connect (OIDC) authentication by configuring the GTW OAuth 2.0 Identity Provider (IdP). Follow these steps to implement OIDC:

digiRunner OIDC Setup Process

1. Create an API Client

🔗 Reference: API Client

Log in to the digiRunner Admin Console.
Navigate to “Client Management” → “API Client”.
Create or edit an API Client that requires OIDC authentication.

2. Add an API Scope or API Group

🔗 Reference: API Scope, API Group

Go to “Client Management” → “API Scope”.
Define API scopes for OIDC, specifying access permissions.
Associate the API Scope with the relevant API Client.

3. Configure GTW OIDC Identity Authentication

🔗 Reference: GTW OAuth 2.0 IdP

3.1 Add a GTW OAuth 2.0 IdP

Navigate to “Client Management” → “GTW OAuth 2.0 IdP”.
Click “Add” to configure a new OIDC identity provider.

3.2 Configure OIDC Identity Provider Details

Fill in the required fields:
- Name → A recognizable name for this IdP.
- Description → Brief details about this IdP’s function.
- Client ID → Retrieved from your OIDC provider.
- Client Secret → Corresponding secret key.
- Authorization Endpoint → The authorization URL of your OIDC provider.
- Token Endpoint → URL to obtain the token.
- User Info Endpoint → URL to fetch user information.
- Redirect URI → The callback URL where users will be redirected after authentication.
Save the settings.

4. Associate the API Client with OIDC

🔗 Reference: API Client

In the API Client settings, select the newly created GTW OAuth 2.0 IdP as its identity provider.

5. Test the OIDC Flow

Use the configured API Client to initiate the OIDC authentication process.
Ensure users can successfully authenticate via the OIDC provider and receive the appropriate access permissions.

🔑 Token Management in digiRunner

digiRunner provides a robust token management system to ensure secure API access and authentication. It supports Access Tokens for authentication and Refresh Tokens for seamless re-authentication without requiring user credentials repeatedly.

Key Features of Token Management in digiRunner:

Token Expiration Control – Configurable expiration times for access and refresh tokens to enhance security.
Scope-Based Permissions – Restricts token access to specific resources following the principle of least privilege.
Token Revocation – Allows administrators to revoke tokens to prevent unauthorized access.
Secure Storage and Transmission – Tokens are securely stored and transmitted using HTTPS to prevent leaks.

To configure token management in digiRunner, follow these steps:

Go to the API Client Management Page: Navigate to the digiRunner admin panel and go to the "API Client Management" section.
Select or Create an API Client: Choose an existing API client from the list or create a new one.
Configure Token Parameters: On the client settings page, configure the following token-related parameters:
- Access Token Expiration: Set the expiration time for access tokens in seconds. A shorter expiration period is recommended for enhanced security.
- Refresh Token Expiration: Set the expiration time for refresh tokens in seconds. This allows the client to obtain new access tokens after the current one expires.
- Scopes (Permissions): Define the resources the client can access. Follow the principle of least privilege and grant only the minimum permissions necessary for the client’s functionality.
Save the Configuration: After completing the above configurations, save your settings.

Please note that specific options and steps may vary depending on the version of digiRunner or your system configuration. It is recommended to refer to the digiRunner Documentation Center for the latest and most detailed guidance.

✅ Best Practices for Implementing OIDC

When integrating OpenID Connect (OIDC) in digiRunner or any authentication system, following best practices ensures security, scalability, and a seamless user experience.

1. Use Authorization Code Flow with PKCE

Why?

This is the most secure way to authenticate clients, especially for public applications (e.g., SPA, mobile apps).
It prevents authorization code interception attacks.

How?

Always enable PKCE (Proof Key for Code Exchange) when using the Authorization Code Flow.
Avoid using Implicit Flow, as it exposes tokens in the URL.

In digiRunner:

Implementation: digiRunner supports the Authorization Code Flow, which is suitable for secure client authentication.
Reference: OpenID Connect (OIDC) Mode

2. Secure Client Credentials & Secrets

Why?

Hardcoded secrets in client-side applications (e.g., JavaScript, mobile apps) expose security risks.

How?

Store client secrets securely in environment variables or a secret management service. • Use JWT-based authentication instead of static secrets when possible.

In digiRunner:

Implementation: Client secrets are generated and stored securely for each API Client registered in digiRunner.
Reference: API Client

3. Implement Token Expiry & Refresh Mechanism

Why?

Short-lived access tokens reduce security risks if a token is compromised.
Refresh tokens allow users to stay authenticated without re-entering credentials.

How?

Set short expiration times for access tokens (e.g., 15–60 minutes).
Use refresh tokens to obtain new access tokens when needed. • Implement automatic token rotation to reduce replay attacks.

In digiRunner:

Implementation: digiRunner supports refresh tokens and token lifecycle management, including introspection and revocation.
Reference: Token Lifecycle Management Mechanism

4. Use Scopes & Claims for Granular Authorization

Why?

OIDC allows defining scopes (e.g., openid, profile, email) to control what user data is shared.
Claims ensure APIs only receive the necessary user attributes.

How?

Define minimal necessary scopes to prevent over-permissioning. • Use custom claims to extend OIDC’s default claims based on business requirements.

In digiRunner:

Implementation: Scopes can be assigned to API Clients to control access based on business rules.
Reference: API Client

5. Validate Tokens Properly

Why?

Accepting invalid or expired tokens exposes your system to unauthorized access.

How?

Always verify:
- Issuer (iss)
- Audience (aud)
- Expiration (exp)
- Signature using public keys

In digiRunner:

Implementation: Token validation is handled by digiRunner and includes issuer, audience, and signature verification.
Reference: OpenID Connect (OIDC) Mode

6. Monitor & Log Authentication Events

Why?

Tracking login attempts, failed authentications, and token usage helps detect suspicious activities.

How?

Enable audit logging for authentication events. • Use SIEM (Security Information & Event Management) tools to analyze logs.
Set up alerts for abnormal login attempts.

In digiRunner:

Implementation: digiRunner supports audit logging and monitoring through the Admin Console.
Reference: Introduction to digiRunner API Management (APIM)

7. Secure Redirection & Callback URLs

Why?

Open redirection vulnerabilities can allow attackers to hijack authentication flows.

How?

Always register a fixed set of redirect URIs with the OIDC provider.
Use exact match validation instead of wildcard patterns (*).

In digiRunner:

Implementation: Redirect URIs must be specified explicitly when configuring OIDC Identity Providers.
Reference: OpenID Connect (OIDC) Mode

8. Avoid Storing Sensitive Data in ID Tokens

Why?

ID tokens should only contain essential authentication-related claims, not sensitive information like passwords.

How?

Store sensitive data in server-side databases instead of ID tokens.
Use access tokens for API authorization and ID tokens only for authentication.

In digiRunner:

Implementation: digiRunner follows OIDC best practices by ensuring only essential claims are included in ID tokens.
Reference: OpenID Connect (OIDC) Mode

9. Enable Multi-Factor Authentication (MFA)

Why?

MFA adds an extra layer of security by requiring users to verify their identity beyond just passwords.

How?

Enforce MFA policies via the OIDC provider.
Support WebAuthn or TOTP-based authentication for better security.

Most major identity providers (IdPs) offer multi-principal authentication (MFA) capabilities.

🔹 Conclusion

Following these best practices helps ensure a secure, scalable, and reliable OIDC implementation. For digiRunner, adhering to these principles enhances both admin console authentication and API client authorization, improving security and user experience.

digiRunner Playbook II: Overview of OpenID Connect (OIDC)