Definition
OAuth2 (Open Authorization 2.0) is an industry-standard authorization framework that allows third-party applications to securely access protected resources on behalf of the user after user authorization, without exposing the user's password. In ICMP, OAuth2 is used together with API Key for RESTful API authentication and integrated with IAM to ensure secure API access and single sign-on for Partner Portal.
Core Concepts
OAuth2 involves the following roles: Resource Owner (the user), Client (the third-party application), Authorization Server (the authorization server), Resource Server (the resource server). The typical flow: the Client guides the user to the Authorization Server for login and authorization; after authorization, it obtains an Access Token; the Client uses the Token to access the Resource Server's API. Tokens have an expiration time and can be renewed using the Refresh Token.
Application in ICMP
ICMP Usage Scenarios for OAuth2: API Authentication——When the customer system calls RESTful API, it can first obtain a token through OAuth2, and then use the token to call; Partner Portal——Channels implement SSO through OAuth2, without separately maintaining passwords; Third-party Integration——When customers integrate ICMP capabilities into their own systems, OAuth2 provides a standard and secure authorization method. The platform API Gateway verifies token validity and permission scope.
Collaboration with API Key
OAuth2 is suitable for interactive scenarios that require user authorization; API Key is suitable for server-to-server, long-term valid scenarios. ICMP can support both: use API Key for simple integration; use OAuth2 for scenarios requiring fine-grained permissions and auditing. Both are managed through IAM and access logs are recorded by Audit Trail.
A Token Hands Over Authorization, Not a Password
On a connectivity platform, OAuth 2.0 lets a caller access specified resources for a short time on behalf of a user or a tenant, without touching the user’s password. The authorization server checks identity and issues an access token. The resource server trusts only the scope, the audience, and the expiry on that token. Accepting a token means this call may do what is inside the scope. It does not mean the caller has become the owner of the account. A refresh token is for obtaining a new access token. It should not itself be used to query SIMs or change invoices.
This authorization fits when a person is present to confirm, or when a registered application needs limited access to an API. An unattended integration that runs for a long time on a fixed basis should use a service credential issued on its own and revocable on its own, not a refresh token written into a script after an employee authorizes once in a browser. Split scope by action, for example read-only usage, permission to suspend a SIM, and permission to export an invoice. Do not use one “all permissions” scope. Tokens should travel under TLS. Where payment or bulk suspension is involved, add two-factor authentication as well, so one token does not carry both sign-in and the ability to move funds.
Scope Too Wide or Lifetime Too Long
A common error is to store an access token in front-end script or in a shared document, and to set it not to expire for several months. Once the token leaks, the holder has the same ability as the granted scope until it expires, and a password change does not necessarily invalidate it. Another error is to ignore audience. A token issued to a reporting system is then used against the SIM-management API. If the resource server does not check audience, the out-of-scope call succeeds.
If the redirect address allows any domain, the authorization code can be sent to a site the attacker controls. The server should also reject a token that has already been revoked, not only check that the signature is correct. When integrating OAuth 2.0, list each caller’s scope, lifetime, allowed callback addresses, and revocation method, and regularly clear authorizations that are no longer used. A token is the credential of one grant. It is not an account that can be passed on.
The consent page should list the resources that will actually be accessed, such as reading usage, suspending a SIM, or exporting an invoice, not only “access the platform on your behalf.” After the user revokes, both access tokens and refresh tokens already issued must become invalid. Disabling refresh alone is not enough. When the server stores a token, keep only check material from which the original value cannot be recovered. When an application is retired, delete its client identity and callback address at the same time, so an old integration cannot keep exchanging a historical grant for a new token.
A public client cannot hold a secret that only a server can keep. The exchange of an authorization code must prevent someone who intercepted it from redeeming the token. A callback address must be registered in advance as a full address. Registering only a domain and then allowing any path is not enough. The scope shown on the consent page must match the scope inside the token. Do not issue a token that can suspend SIMs after the user consented to “read-only usage.” The resource server checks signature, expiry, audience, and scope together. If any one is missing, it rejects the call.
A refresh token is stored differently from an access token. An access token is short-lived and can sit in the current session. A refresh token is long-lived and may sit only on the caller’s server side. It must not sit in browser script or in plaintext storage on a mobile app. On refresh, the old refresh token can be invalidated by policy, so a leaked refresh token is not used again and again. After the user changes the password, or an administrator revokes the grant, both kinds of token become invalid. It is not enough for the next refresh to fail while the current access token keeps working.
A long-running call between services should not be disguised as an employee’s grant. When the employee leaves, refresh tokens hanging under that person fail together and the integration stops suddenly. If revocation is forgotten at departure, the integration keeps acting as that person. A machine call uses its own client and the smallest scope, and the log shows the client name. An audit can then tell a person clicking in the portal from a system synchronizing on a schedule.
Show the scope inside a token as action names the caller can understand. Do not show only an internal number. After the user revokes one scope, the next call should lose that ability. It should not wait until the token expires on its own.