OAuth 2 client credentials is the machine-to-machine authentication flow that lets a SCADA gateway prove who it is to a cloud API without any human logging in. Instead of hard-coding a permanent API key into a header, the gateway holds a client ID and secret, exchanges them for a short-lived bearer token, and presents that token on each request. When the token expires, it quietly fetches a new one. This page explains the grant itself, how to cache and refresh tokens before they lapse, how scopes enforce least privilege, and why this pattern is safer than a static key.
OAuth 2 client credentials for SCADA APIs in one line: The OAuth 2 client credentials grant is a server-to-server flow where an integration exchanges a client ID and secret at a token endpoint for a short-lived bearer token, then sends that token on each API call. It suits SCADA-to-cloud REST integrations because no user is involved, tokens expire quickly to limit exposure, and scopes restrict what the token can do.
Client credentials is the branch of OAuth 2 designed for the case where there is no user, only two systems talking to each other. The integration, acting as its own identity often called a service principal, holds a client ID and a client secret issued when it was registered with the API. To authenticate, it makes a single POST to the authorization server's token endpoint, presenting those credentials and the scopes it wants. The server validates them and returns an access token, typically a bearer token, along with how long it is valid.
From that point the token does the work. The integration attaches it to each REST request in an Authorization header as a bearer credential, and the API validates the token rather than re-checking the client secret every time. This separation matters: the long-lived secret is used sparingly, only at the token endpoint, while the token that travels on every request is short-lived and disposable. If that token leaks, it stops working within minutes to hours, which sharply limits the damage compared with a leaked permanent key.
The whole exchange is stateless from the API's side. The token itself, often a signed JSON structure, carries the client identity, the granted scopes, and an expiry, so the API can verify it cryptographically without a database lookup on every call. This is what lets the pattern scale to many field gateways all calling the same cloud endpoint, each holding its own credentials and its own token, without the API tracking sessions for each one.
A common beginner mistake is to fetch a fresh token on every single API call, which hammers the token endpoint and adds a round trip to each request for no reason. The correct pattern is to fetch a token once, cache it in memory alongside its expiry time, and reuse it for every request until it is close to expiring. Because the token response tells the integration how many seconds the token lives, the client can compute an expiry and keep using the same token for the whole window.
Refresh should happen proactively, before the token actually lapses, not after a request has already failed. A good client refreshes when the token has, say, thirty to sixty seconds of life left, so there is always a valid token in hand and requests never stall waiting for authentication. That said, the integration must still handle the case where the API rejects a token as expired anyway, perhaps because of clock skew or an early server-side revocation, by fetching a new token and retrying the request once. The client credentials grant does not use OAuth refresh tokens; the integration simply requests a brand-new access token from the token endpoint whenever it needs one.
Scopes are how this pattern enforces least privilege. When registering, the integration is granted only the scopes it genuinely needs, for example a scope that permits writing telemetry but not reading account data or changing configuration. The token it receives is stamped with those scopes, and the API refuses any operation outside them. This means a compromised field gateway can only do the narrow thing it was allowed to do, rather than holding the keys to the entire tenant, which is a level of control a single all-powerful API key simply cannot offer.
A static API key placed in a header is convenient and, for exactly that reason, dangerous. It usually does not expire, so once it leaks it is valid until someone notices and rotates it, which may be months later. It travels on every request just like a token would, but unlike a short-lived token there is no natural window that closes on a leak. And because a single key typically grants broad access, its loss compromises far more than one narrow capability. Rotating it means coordinating a swap across every device that holds it, often a painful manual exercise.
Client credentials tokens invert all of these weaknesses. The credential that travels constantly, the bearer token, expires on its own within a short window, so a captured token is worthless almost immediately. The long-lived secret stays put and is only presented to one endpoint, reducing its exposure. Scopes cut each integration down to only what it needs, and revocation is straightforward because the authorization server can refuse to issue new tokens to a compromised client without touching anything else. Rotating a secret is a single change at one identity rather than a fleet-wide key swap.
For a cloud SCADA service like Merobix ingesting telemetry from many customer sites, this is the difference between a defensible authentication model and a fragile one. Each field gateway authenticates as its own identity with narrowly scoped, short-lived tokens, so onboarding a new site, revoking a decommissioned one, or containing a suspected compromise is a controlled operation that does not put the rest of the platform at risk. The extra step of a token exchange is a small price for authentication that ages gracefully and fails safely.
No. The client credentials flow does not issue refresh tokens because there is no user session to maintain. When the access token expires, the integration simply calls the token endpoint again with its client ID and secret to obtain a fresh access token. Refresh tokens belong to user-facing flows like authorization code, not to machine-to-machine ones.
Cache it for as long as the token response says it is valid, minus a small safety margin so you refresh a little before it actually expires. The token response includes an expiry, often expressed in seconds, and the client should compute the absolute expiry time and reuse the token until then. Refreshing thirty to sixty seconds early avoids requests stalling on authentication.
A permanent key usually never expires, so a leak stays exploitable until someone rotates it, and it typically grants broad access that widens the blast radius. Client credentials tokens are short-lived, so a captured token dies on its own within minutes to hours, and scopes restrict each integration to only what it needs. The result is authentication that ages gracefully and contains damage automatically.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.