Infohub (Flow)How-to

OAuth 2.0 for Web Service Sources

Grant types, client authentication methods, and Private Key JWT — configuring OAuth 2.0 without guesswork.

Updated 15 Oct 2026Infohub Docs

Most modern APIs authenticate with OAuth 2.0. Infohub's Web Service connector supports it directly, including the certificate-based Private Key JWT method that enterprise identity providers such as Microsoft Entra ID require.

OAuth has a lot of moving parts and its error messages are famously unhelpful. This article works through the properties in the order you need to decide them.

Start with the provider's documentation#

Before touching Infohub, get four facts from whoever owns the API:

The token endpoint URL.
Which grant type to use.
How the client authenticates to the token endpoint — a secret, or a signed assertion.
Which scopes the token needs.

Every OAuth failure that takes more than ten minutes traces back to one of these being assumed rather than confirmed.

Choosing a grant type#

Set Authentication to OAuth 2.0, then choose the Grant Type.

Grant Type	Use when	Notes
Client Credentials	Infohub authenticates as itself, no user involved	The right answer for almost all Infohub integrations
jwt-bearer	The provider expects a signed JWT assertion as the grant	Used by some enterprise providers
Authorization Code	A user must consent interactively	Requires an authorisation code and redirect URI
Refresh Token	You hold a long-lived refresh token
Auto	Let the connector determine it	Useful when starting out

Client Credentials is what you want for server-to-server data collection. Infohub is a background service; there is no user sitting in front of it to consent to anything.

Important

Authorization Code fits Infohub poorly. The Authorization Code grant assumes a browser and a person. Infohub retrieves data unattended, so a flow requiring periodic human consent will eventually stop overnight. If a provider only offers Authorization Code, ask them for a service-principal or client-credentials option before building on it.

Choosing a client authentication method#

Client Authentication determines how Infohub proves its identity to the token endpoint. This is separate from the grant type, and confusing the two is the most common configuration error.

Method	How it works
Client Secret Post	Client ID and secret in the request body
Client Secret Basic	Client ID and secret in an HTTP Basic header
Private Key JWT	A JWT signed with your private key, no shared secret
None	Public client, no client authentication

The two secret-based methods are equivalent in security and differ only in where the credentials are placed. Providers usually accept one and not the other — use whichever the documentation specifies rather than assuming.

Client Credentials with a secret#

The common case, and the simplest.

Property	Value
Grant Type	`Client Credentials`
Client Authentication	`Client Secret Post` or `Client Secret Basic`
Token url	The provider's token endpoint
Consumer Key	The client ID
Client Secret	The client secret
Scope	Whatever scopes the token needs

Scope deserves care. Too few scopes and the token is issued but the API refuses the request — which looks like an authorisation problem at the wrong layer. Too many and the token is more privileged than it needs to be. Ask for exactly what the endpoints you read require.

Private Key JWT#

The certificate-based method, and the one enterprise providers increasingly mandate. Instead of a shared secret, Infohub builds a JWT assertion and signs it with a private key you hold, and the provider validates it against the matching public key.

Property	Notes
Client Authentication	`Private Key JWT`
Private Key	The signing key
Private Key ID	The key identifier, so the provider knows which public key to check against
Security Algorithms	Signing algorithm — RS256 by default
Client Assertion Type	`jwt-bearer`
Claims	Additional or overriding claims in the assertion

RS256 is the default because it is what the great majority of providers expect. Change it only if the provider documents a different algorithm.

Private Key ID matters when the provider holds more than one public key for your client. Omitting it where the provider needs it produces a signature-validation failure rather than anything mentioning key selection.

Claims that Infohub fills in for you#

A JWT assertion needs standard claims, and Infohub supplies sensible values automatically so you do not have to:

jti — a unique identifier, freshly generated for every assertion. Providers reject replayed assertions, so this must differ each time; Infohub makes a new one per request unless you pin it explicitly in Claims.
sub — the subject, defaulting to the client ID, which is what most providers expect.

Use the Claims property only to add claims the provider specifically requires, or to override a default when you know you need to. Pinning jti to a fixed value will cause the second request to be rejected as a replay.

Tip

Microsoft Entra ID is the common target. Entra ID is the provider most Infohub deployments meet that requires Private Key JWT. Configure Grant Type Client Credentials, Client Authentication Private Key JWT, Security Algorithms RS256, Client Assertion Type jwt-bearer, and register the certificate's public key against the app registration. Get the Private Key ID from the certificate's thumbprint as the registration reports it.

Token handling#

Infohub manages tokens for you, and it is worth knowing how so that you can reason about failures.

Tokens are cached and reused rather than re-requested per call, so a burst of measures does not produce a burst of token requests.

The cache is keyed per configuration. Two connections with different credentials do not share a token, and one connection's token does not leak into another's requests.

Expiry is handled with a margin, so a token is renewed slightly before it actually expires rather than after a request has already failed.

A revoked token recovers automatically. If a provider invalidates a token before its stated expiry — a revocation, a credential rotation, a provider-side reset — Infohub discovers this from the rejected request, discards the cached token, and acquires a fresh one rather than failing repeatedly until expiry.

That last behaviour matters operationally: a mid-shift credential rotation on the provider side heals itself rather than requiring someone to restart the connection.

Certificate validation#

Validate Server Certificate defaults to False, permissively, so that development against self-signed endpoints works immediately.

Turn it on for any real service, and particularly for an OAuth token endpoint. Certificate validation is exactly what stops credentials being presented to something impersonating the identity provider. Leaving it off on a token endpoint is the least appropriate place in the whole configuration to be permissive.

Working through a failure#

OAuth errors are terse. Establish which stage failed before changing anything, because the two stages have entirely different causes.

Token stage — Infohub cannot obtain a token at all. The problem is in the token endpoint, grant type, client authentication method, credentials, key, or algorithm.

Data stage — a token was obtained but the API rejects the request. The token is fine and the problem is scope, permissions on the resource, or the request itself — usually a header or an endpoint path.

Distinguishing them removes most of the guesswork:

Symptom	Stage	Likely cause
No token issued, invalid client	Token	Wrong client authentication method, or wrong credentials
No token issued, invalid grant	Token	Wrong grant type for this client
Signature validation failed	Token	Private key, Private Key ID, or algorithm
Assertion rejected as replayed	Token	`jti` pinned to a fixed value in Claims
Token issued, API returns unauthorised	Data	Scope insufficient, or the header is malformed
Token issued, API returns forbidden	Data	The client lacks permission on that resource
Worked, then failed, then recovered	—	Expected: a revoked token being discarded and reacquired
Worked for months, now fails	Token	Client secret or certificate expired