- 28
- March
What Is OAuth 2.0? — The Authorization Standard Every ERP Must Support
OAuth 2.0 (Open Authorization 2.0) is an open standard for authorization that allows one application to access a user's data on another system without knowing the user's password. For example, when an ERP system needs to pull data from the e-GP procurement system or integrate with ThaiD for identity verification, OAuth 2.0 is the mechanism that makes it happen securely.
Quick Summary: OAuth 2.0 = a standard for "granting access" (Authorization), not "proving identity" (Authentication). Apps request Tokens instead of passwords, enabling secure integration with external systems while users control exactly what data can be accessed.
How Does OAuth 2.0 Work?
OAuth 2.0 defines 4 key roles that work together:
| Role | Definition | ERP Example |
|---|---|---|
| Resource Owner | The data owner (user) who grants consent for an app to access their data | An officer who clicks "Allow" to let the ERP pull data from ThaiD |
| Client | The application that wants to access the data; must be registered with the Authorization Server | Saeree ERP requesting data from an external system |
| Authorization Server | The server that verifies the user's identity and issues Access Tokens to the Client | ThaiD server, GFMIS server |
| Resource Server | The server hosting the data (API); accepts only requests with valid Access Tokens | e-GP API, GFMIS API |
The Authorization Code Flow (Step by Step)
The most common and most secure flow works as follows:
| Step | What Happens | Details |
|---|---|---|
| 1 | User clicks "Log in with ThaiD" | The Client (ERP) redirects the user to the Authorization Server's login page |
| 2 | User authenticates and grants consent | The Authorization Server verifies identity and asks: "Allow this ERP to access your data?" |
| 3 | Authorization Server returns an Authorization Code | A temporary code sent via browser redirect back to the ERP |
| 4 | Client exchanges Code for Access Token | The ERP sends Code + Client Secret to the Authorization Server via back-channel (server-to-server) |
| 5 | Client uses Access Token to call the API | The ERP includes the Token with every request to fetch data from the Resource Server |
The 4 OAuth 2.0 Grant Types
OAuth 2.0 supports 4 methods for obtaining tokens (Grant Types), each suited to different scenarios:
| Grant Type | When to Use | Security Level | Status |
|---|---|---|---|
| Authorization Code | Web apps, Mobile apps with a back-end server | Highest — Token exchanged via back-channel | Recommended (most widely used) |
| Authorization Code + PKCE | Mobile apps, SPAs without a Client Secret | High — adds code_verifier to prevent interception | Recommended for mobile/SPA |
| Client Credentials | Server-to-server (no user involved) | High — uses Client ID + Secret | Recommended (M2M) |
| Implicit | Legacy SPAs without a back-end | Low — Token sent via URL fragment | Deprecated |
| Resource Owner Password | Legacy apps that must send username/password directly | Low — Client sees the user's password | Not recommended |
Best Practice: The IETF currently recommends Authorization Code + PKCE for all client types (both web and mobile) and Client Credentials for server-to-server communication only. Other grant types should not be used in new systems.
OAuth 2.0 vs Authentication — What's the Difference?
Many people confuse OAuth 2.0 with authentication. In reality, OAuth 2.0 is authorization (granting access), not authentication (proving who you are):
| Aspect | OAuth 2.0 (Authorization) | Authentication | OpenID Connect (OIDC) |
|---|---|---|---|
| Question answered | "What can this app do?" | "Who are you?" | Answers both questions |
| Result | Access Token (permission to access) | Identity verified / not verified | Access Token + ID Token |
| Example | ERP fetching data from an external API | User logging in with a password | Logging in with ThaiD to access ERP |
| Standard | RFC 6749 | Various (LDAP, SAML, etc.) | Built on top of OAuth 2.0 |
OpenID Connect (OIDC) is a protocol built on top of OAuth 2.0 that adds authentication capabilities by returning an ID Token (JWT) alongside the Access Token. This tells the application both "who the user is" and "what they can access" — this is exactly what ThaiD Login uses.
OAuth 2.0 vs API Key vs Basic Auth
Comparing common methods for API authentication and authorization:
| Aspect | OAuth 2.0 | API Key | Basic Auth |
|---|---|---|---|
| How credentials are sent | Bearer Token in Header | Key in Header or URL | Base64-encoded username:password |
| Security | High — Token expires, has Scope, revocable | Moderate — no expiry, hard to revoke | Low — password sent with every request |
| Scope control | Yes (fine-grained Scope) | Limited (all-or-nothing per key) | No (full access) |
| Third-party support | Yes — designed for this purpose | Partially | Not suitable |
| Best suited for | ERP systems, Single Portal, ThaiD | Internal APIs, Webhooks | Legacy systems, testing |
Why Must ERP Systems Support OAuth 2.0?
As government systems become increasingly interconnected, OAuth 2.0 has become an indispensable standard:
- Government Single Portal — The Thai government requires agencies to share data via standardized APIs. OAuth 2.0 is the foundation of these interconnections.
- ThaiD Login — Thailand's national digital identity system uses OpenID Connect (built on OAuth 2.0). An ERP that supports OAuth 2.0 can integrate with ThaiD immediately.
- External system integration — Whether it's GFMIS, e-GP, e-Tax Invoice, or banking systems, OAuth 2.0 is the standard they all support.
- API Economy — In an era where systems must "talk to each other," OAuth 2.0 enables ERP interoperability securely and in a standardized way.
- Security — No need to store other systems' passwords. Tokens expire, can be revoked instantly, and Scopes can be defined with fine granularity.
Real-World Use Cases in Saeree ERP
| Use Case | Grant Type Used | Details |
|---|---|---|
| ThaiD Login | Authorization Code + PKCE (OIDC) | Users log in with ThaiD; the ERP receives an ID Token + Access Token without storing passwords |
| Inter-agency API | Client Credentials | Saeree ERP sends budget data to GFMIS using Client ID/Secret for server-to-server token exchange |
| e-GP Integration | Client Credentials | Automatically pulls procurement data from the e-GP system using time-limited tokens |
| Digital Signature | Authorization Code | Users authorize the ERP to invoke an external CA's digital signature service on their behalf |
Key OAuth 2.0 Terminology
| Term | Definition |
|---|---|
| Access Token | A token proving the application has been authorized to access a resource. Has a limited lifespan (e.g., 15-60 minutes) and is sent with every API request. |
| Refresh Token | A token used to obtain a new Access Token without requiring the user to log in again. Has a longer lifespan (e.g., 7-30 days). |
| Scope | The range of permissions an application requests from the user, e.g., read:profile, write:documents. Helps enforce the Principle of Least Privilege. |
| Bearer Token | The format for sending an Access Token in an HTTP Header: Authorization: Bearer <token>. Anyone with the token can use it, so HTTPS is mandatory. |
| PKCE (Proof Key for Code Exchange) | A security enhancement for the Authorization Code Flow using code_verifier + code_challenge to prevent authorization code interception. |
| OpenID Connect (OIDC) | A protocol built on OAuth 2.0 that adds Authentication by returning an ID Token (JWT). Examples: ThaiD Login, Google Login. |
| JWT (JSON Web Token) | A token format that encodes user information within itself, verifiable without a database lookup. Used as the ID Token in OIDC. |
| Consent Screen | The screen that asks users: "Allow this app to access your data?" Displays the Scopes the app is requesting. |
How OAuth 2.0 Relates to RBAC
OAuth 2.0 and RBAC (Role-Based Access Control) operate at different levels but complement each other:
- OAuth 2.0 — controls "which app can access which API" (Application level)
- RBAC — controls "which user can see which menu" (User level)
- Used together — after a user logs in via OAuth 2.0/OIDC, the ERP system uses RBAC to determine what data that user can see
- Combined with 2FA — adds another security layer with Two-Factor Authentication before issuing tokens
