- 28
- March
What Is OpenID Connect (OIDC)? — The Authentication Standard Built on OAuth 2.0
OpenID Connect (OIDC) is an authentication protocol built as an identity layer on top of OAuth 2.0. It enables applications to not only know "what resources the user has granted access to" but also "who the user is" — such as their name, email, and national ID number — through an ID Token in JWT format.
Quick Summary: OAuth 2.0 = "grant access to resources" (Authorization). OIDC = "prove who you are" (Authentication) + Authorization. OIDC adds the ID Token to convey user identity information, so the ERP system knows exactly who is using it.
OAuth 2.0 vs OIDC — What's the Difference?
Many people confuse OAuth 2.0 with OIDC because OIDC is built on top of OAuth 2.0, but they serve different purposes:
| Aspect | OAuth 2.0 | OpenID Connect (OIDC) |
|---|---|---|
| Primary Function | Authorization (grant access to resources) | Authentication + Authorization (verify identity + grant access) |
| Question It Answers | "Does this app have permission to access my data?" | "Who is this user?" + "What can they access?" |
| Tokens Issued | Access Token only | ID Token + Access Token |
| User Information | No standard (must call API separately) | Standard Claims (name, email, sub) in the ID Token |
| Discovery | None | .well-known/openid-configuration available |
| Example Usage | App requests access to user's Google Drive | "Sign in with Google" or "Sign in with ThaiD" |
How Does OIDC Work? — Authorization Code Flow
The recommended flow for ERP systems is the Authorization Code Flow, the most secure flow suitable for web applications with a backend server:
| Step | Actor | Details |
|---|---|---|
| 1. User Clicks Login | User | Clicks "Sign in with ThaiD" button on the ERP login page |
| 2. Redirect to OpenID Provider | ERP App | Sends request to Authorization Endpoint with scope=openid, response_type=code, redirect_uri, state, nonce |
| 3. User Authenticates | OpenID Provider | User logs in at ThaiD (face scan, PIN) and consents to share information |
| 4. Authorization Code Returned | OpenID Provider | Redirects back to ERP with a one-time-use Authorization Code |
| 5. Exchange Code for Tokens | ERP Backend | Sends Code + client_secret to Token Endpoint, receives ID Token + Access Token |
| 6. Validate ID Token | ERP Backend | Verifies signature, iss, aud, exp, nonce, then reads Claims (name, ID number, email) |
| 7. Create Session | ERP Backend | Maps user info to ERP user account, creates session for successful login |
Key Point: The Authorization Code is sent via the browser (front-channel), but the token exchange happens at the backend (back-channel). This means the Access Token and ID Token are never exposed to the browser directly — significantly improving security.
ID Token vs Access Token — Comparison
OIDC issues two types of tokens with different purposes:
| Aspect | ID Token | Access Token |
|---|---|---|
| Purpose | Authentication — "Who is the user?" | Authorization — "What can they do?" |
| Format | Always JWT (Header.Payload.Signature) | May be JWT or opaque string |
| Contains | sub, name, email, iss, aud, exp, nonce | scope, permissions (provider-dependent) |
| Lifetime | Short (5-60 minutes) — used once to create session | Short-to-medium (1-24 hours) — used repeatedly for API calls |
| Who Validates | Client (ERP application) validates it | Resource Server (API Server) validates it |
| Where It's Sent | Not sent to APIs — used internally by client only | Sent in Authorization header when calling APIs |
Key OIDC Terminology
Essential terms that implementation teams must understand when integrating an ERP system with an OpenID Provider:
| Term | Definition | Example |
|---|---|---|
| ID Token | A JWT issued by the OpenID Provider containing user identity information | eyJhbGciOiJSUzI1NiIs... (3-part JWT) |
| Claims | Individual data fields within a token, such as name, email, national ID | "sub": "1234567890", "name": "Somchai", "email": "..." |
| UserInfo Endpoint | An API that provides additional user information; requires an Access Token | GET /userinfo with Bearer token |
| Issuer (iss) | URL of the OpenID Provider that issued the token | https://thaid.goth.or.th, https://accounts.google.com |
| Subject (sub) | A unique identifier for the user assigned by the Issuer | "sub": "110248560174256879" (Google), 13-digit ID (ThaiD) |
| Nonce | A random value created by the client, sent in the request and verified in the ID Token to prevent replay attacks | "nonce": "abc123xyz" |
| JWT (JSON Web Token) | A standard format for securely transmitting data; consists of 3 parts: Header, Payload, Signature | xxxxx.yyyyy.zzzzz (Base64 encoded) |
| Discovery Document | A JSON file at .well-known/openid-configuration describing all Provider metadata | authorization_endpoint, token_endpoint, jwks_uri, supported scopes |
OIDC and Single Sign-On (SSO) — Why OIDC Is the Modern SSO Standard
SSO (Single Sign-On) allows users to log in once and access multiple systems without re-authenticating. OIDC has become the modern SSO standard because it is easy to use, supports both web and mobile platforms, and features a Discovery Document that enables rapid integration:
| Aspect | OIDC | SAML 2.0 | LDAP |
|---|---|---|---|
| Year Published | 2014 | 2005 | 1993 |
| Data Format | JSON / JWT | XML | Binary (ASN.1) |
| Mobile Support | Excellent (lightweight JSON, OAuth-based) | Limited (heavyweight XML) | Not directly supported |
| Integration Complexity | Low — Discovery Document + abundant libraries | Medium-High — requires XML metadata configuration | High — requires schema + firewall configuration |
| SSO | Supported (via session at OpenID Provider) | Supported (primary strength) | Not SSO directly (paired with Kerberos) |
| Example Providers | Google, ThaiD, Azure AD, Keycloak | ADFS, Shibboleth, Okta | Active Directory, OpenLDAP |
| Best Suited For | Modern web + mobile + API | Legacy enterprise SSO | Internal network, directory services |
Why Must ERP Systems Support OIDC?
As the Thai government pushes for Digital Government, OIDC support in ERP systems is no longer optional — it has become a requirement:
- ThaiD Login uses OIDC — Thailand's digital identity system by the Department of Provincial Administration (DOPA) uses OIDC as its primary protocol. Government agencies integrating with ThaiD must support OIDC.
- Government Single Portal — The Digital Government Plan 2025-2027 mandates that government agencies use a centralized login system (SSO) so citizens can access multiple agency services with a single account.
- Reduced password management burden — With OIDC, the ERP system doesn't need to store passwords itself, reducing the risk of password data breaches.
- 2FA handled by the Provider — The OpenID Provider (e.g., ThaiD) manages Multi-Factor Authentication independently, so the ERP system doesn't need to implement 2FA separately.
- API Authentication — ERP systems that expose APIs to external systems (e.g., GFMIS, e-GP) can use OIDC-issued Access Tokens to verify the identity of calling systems.
Example in Saeree ERP
Saeree ERP supports OIDC for integration with government identity systems:
| Use Case | OpenID Provider | Information Received |
|---|---|---|
| ThaiD Login | ThaiD (DOPA) | National ID number, full name, date of birth |
| Government Agency SSO | Agency's Keycloak / Azure AD | Employee ID, position, department, email |
| API Authentication | Saeree ERP (as Resource Server) | Validates Access Tokens from external clients |
When a user successfully logs in via ThaiD, Saeree ERP maps the national ID number (sub claim) to the user account in the system and assigns a Role (RBAC) based on the pre-configured position — the user doesn't need to remember a separate password for the ERP system.
Important for Implementation Teams: When integrating OIDC, always validate the ID Token — verify the signature using JWKS, check that iss matches the expected provider, check that aud matches your client_id, check that exp has not passed, and verify that nonce matches the value you sent.
