System authentication: OAuth2 grants, scopes, token lifetimes and certificate rotation

System authentication is how one system proves its identity to another, and it is different from customer authentication in kind, not just in degree. A customer proves who they are with something they know, have or are; a system proves who it is with a credential it holds, usually a client secret, a certificate, or a signed assertion. The credential is issued by the bank, stored securely by the client system, and presented on every call. If the credential is stolen, the thief can act as the client system, so the credential must be protected, rotated, and revocable. This lesson teaches the OAuth2 grant types, the scopes, the token lifetimes and the certificate rotation that a payments SME must be able to specify and test. Source: RFC 6749 OAuth 2.0 Authorization Framework; RFC 7523 JWT bearer tokens; bank API developer documentation. OAuth2 has four grant types, and each fits a different integration pattern. The client credentials grant is the one most payment APIs use for system to system calls: the client presents its client identifier and client secret to the token endpoint and receives an access token. There is no user involved, which is correct, because a treasury system paying 500 suppliers does not have a user sitting at a keyboard. The authorization code grant is for applications that act on behalf of a user: the user logs in and consents, and the application receives a code it exchanges for a token. The refresh token grant lets a client obtain a new access token without asking the user to log in again. The device code grant is for devices with no keyboard. A business analyst must specify which grant type each integration uses, because the wrong grant type is a security defect: a system to system integration that uses the authorization code grant has a user interaction it does not need, and a user facing application that uses the client credentials grant has no user consent at all. Scopes limit what an access token can do, and they are the mechanism that enforces least privilege. A token with scope payments:read can read payment status but cannot create a payment. A token with scope payments:write can create a payment but cannot read account balances. A treasury system that only needs to pay suppliers should receive a token with scope payments:write and nothing else, so that if the token is stolen, the thief can create payments but cannot read the account, and cannot, for example, enumerate the bank's customers. Scopes are requested by the client when it asks for a token, and granted by the bank based on what the client is entitled to. A client that asks for a scope it is not entitled to receives an error, and the bank logs the attempt. For a business analyst, the requirement is to define the scope for each operation, the scope each client type is entitled to, and the error returned when a client asks for a scope it does not have. Token lifetimes balance security against usability. An access token for a payment API typically lives for 5 to 15 minutes, because a short lived token limits the damage if it is stolen: a thief has minutes, not hours, to use it. A refresh token lives longer, typically hours or days, and is used to obtain a new access token without asking the user to log in again. When an access token expires, the client presents its refresh token to the token endpoint and receives a new access token. If the refresh token is also expired, the client must authenticate again. The bank must also be able to revoke a token immediately, for example when a client reports a compromise, and revocation must take effect within seconds, not at the next token expiry. A client that continues to use a revoked token must receive a 401 Unauthorized response. For a business analyst, the requirement is to define the access token lifetime, the refresh token lifetime, and the revocation behaviour, and to test each with a real call. Certificate rotation is how a bank replaces the certificates that systems use to authenticate, without breaking the integration. A certificate has an expiry date, typically one year, and the bank must issue a new certificate and the client must install it before the old one expires. The safe way to do this is to run two certificates in parallel during a transition period: the bank accepts both the old and the new certificate, the client installs the new one, verifies it works, and then the bank stops accepting the old one. This is the same pattern as API versioning: the old and new run side by side, then the old is retired. A certificate that expires without a replacement breaks the integration completely, and the client cannot send or receive payments until a new certificate is installed. The bank must therefore notify the client well before expiry, typically 90, 30 and 7 days before, and must have a process for emergency rotation if a certificate is compromised. Last reviewed 7 November 2026. Further reading: RFC 6749 OAuth 2.0 Authorization Framework; RFC 7523; bank API developer documentation.