System authentication: OAuth2 grants, scopes, tokens and certificates

System authentication is the control where one system proves its identity to another system, with no person involved. When a corporate treasury system calls a bank API, or when a payment hub calls a sanctions screening service, the receiving system must know which system is calling, whether that system is who it claims to be, and whether it is still trusted. This is different from customer authentication, where a person proves who they are. System authentication uses credentials that belong to a system: a client identifier and secret, or a certificate. If that proof fails, the call is refused, even if the message itself is perfectly formed. Customer authentication is taught in ch26s5 Customer authentication; this lesson covers the system side. OAuth 2.0 is the framework most payment APIs use for system authentication, and the grant type decides how the token is obtained. The client credentials grant is used when no user is present: the calling system presents its client identifier and secret and receives an access token for itself. The authorization code grant is used when a user is present: the user approves the access, and the calling system receives a token that acts on that user's behalf. Choosing the wrong grant is a real design error. A batch treasury system that pays suppliers overnight cannot use the authorization code grant, because no user is awake to approve it. A mobile app that acts for a customer cannot use the client credentials grant, because the token would carry the app's identity instead of the customer's. Scopes decide what a token is allowed to do, and they are the enforcement point for least privilege. A token with the payments:read scope can enquire about a payment but cannot create one. A token with the payments:write scope can create a payment but cannot cancel one unless it also holds the cancellation scope. When a system calls an operation its token does not cover, the API returns 403 Forbidden, which means the caller is authenticated but not allowed. A business analyst must define the scope for every operation in the API, because a scope set too wide lets a compromised system do damage, and a scope set too narrow breaks genuine calls in production. Token lifetimes and refresh decide how long a token stays valid and what happens when it expires. An access token typically lives for minutes or hours, not days, so that a stolen token is useful only briefly. A refresh token lives longer and is used to obtain a new access token without asking the user to authenticate again. The refresh token must be stored securely and rotated on use, because a stolen refresh token is as dangerous as a stolen password. A payment file that takes hours to process must handle token expiry in the middle: the calling system refreshes the token and retries with the same idempotency key, so the payment is not executed twice. Mutual TLS, known as mTLS, is the transport layer proof that both sides are who they claim to be. In ordinary TLS only the server proves its identity with a certificate. In mTLS the client also presents a certificate, so the server knows which system is calling before any application data is exchanged. Many banks require mTLS for open banking and corporate API access, alongside OAuth2. The certificate is the identity, which means certificate management is security management: the bank must know which certificates are issued, when each one expires, and how to revoke one quickly if a system is compromised. Certificate rotation is the operational discipline that keeps mTLS working. Certificates expire, and an expired certificate stops the API call as surely as a wrong password. A bank that forgets to rotate a certificate causes an outage that looks like a system failure but is really an identity failure. Good practice is to rotate certificates well before expiry, to run both the old and the new certificate during a transition window, and to alert on expiry at 90, 30 and 7 days. The runbook must state who rotates the certificate, how the new one is distributed to every calling system, and what happens if a rotation fails on a Friday evening. Worked example. A corporate treasury system pays 500 suppliers every Friday, worth 1.2 million pounds, through the bank API. The system authenticates with the client credentials grant and receives an access token with the payments:write scope, valid for one hour. The file takes ninety minutes to process, so the token expires after the 300th payment. The treasury system uses its refresh token to obtain a new access token and continues, retrying the 301st payment with the same idempotency key so it is not executed twice. If the refresh token had been stolen, the attacker could obtain new access tokens until the refresh token is revoked, which is why refresh tokens are stored in a vault and rotated on every use. Failure modes for system authentication are different from customer authentication failures, and the recovery is different too. An expired certificate causes every call from that system to fail at the transport layer, and the fix is a certificate rotation, not a password reset. A leaked client secret lets an attacker obtain tokens as the system, and the fix is to revoke the secret, issue a new one, and review every token issued with the old secret. A scope error returns 403 Forbidden, and the fix is to correct the scope assignment, not to re-authenticate. Clock skew between systems can make a freshly issued token look expired, and the fix is time synchronisation, not a new token. Each failure has its own symptom, its own log entry and its own runbook. For a business analyst, product owner or subject matter expert, the test is to state, for every system to system call, which grant type applies, which scopes the token carries, how long the token lives, how it is refreshed, whether mTLS is required, and how certificates are rotated. The requirement must name the grant, the scopes, the lifetimes, the rotation runbook and the failure handling for each of those items. A common design error is to specify OAuth2 without specifying the grant, which leaves the implementer to guess. Another is to forget certificate rotation, which turns a security control into a future outage. Last reviewed 7 November 2026.