invokationOne authorized connection, without a token loop in every caller
Your backend authenticates to Invokation and invokes an authorized connection profile. The profile resolves its protected credential references, obtains or reuses the downstream token, and applies authentication to the permitted destination request. Your application does not fetch or receive the provider credential by default.
This is managed authentication for the APIs your application calls. Provider accounts, authorization grants, permissions, and adapter semantics still need to be configured. The marketing site contains only explanations and local simulations; it accepts no provider credentials.
Protected credentials with an explicit boundary
The platform design calls for encryption at rest and in transit, restricted runtime access, and isolation between connections, environments, and customers. Profiles reference secret versions rather than embedding values in Git. Replacement, revocation, and deletion should be controlled actions with audit events that omit secret values.
Credential use must be restricted to approved endpoints, methods, audiences, and permissions. Validate redirects and destination changes before attaching authentication; an arbitrary URL supplied by a caller must not receive a profile’s secret. A dedicated IP is a routing choice, not a credential boundary or proof of complete isolation. These are product design requirements, not an assertion of an implemented, audited vault or certification.
Choose the strategy the destination actually supports
| Strategy | What the connection manages | What still needs deliberate configuration |
|---|---|---|
| API key / static bearer | Protected reference, configured header injection, redaction, replacement | Account permissions, rotation ownership, destination restrictions |
| OAuth client credentials | Token acquisition, usable-token reuse, expiry, reissuance | Approved client, token endpoint, audience and scopes |
| Delegated OAuth | Supported authorization-code/PKCE exchange, issued refresh tokens, rotation, reconnect state | Initial provider authorization, consent, provider rules |
| Custom token / JWT endpoint | Documented auth request, response mapping, expiry and renewal contract | Approved credential use, token format, lifetime source |
| Supported API session | Session acquisition and renewal under a documented API contract | Provider support and explicit policy; no browser-login automation |
OAuth client credentials generally obtains another access token rather than relying on a refresh token. Delegated flows may issue refresh tokens whose rotation and revocation must follow provider behavior and current OAuth security practice. An API key is not an expiring OAuth token. JWT describes a token format; a custom API can issue a JWT without implementing OAuth.
The lifecycle behind a request
- Resolve the authorized profile, environment, credential version, and authentication strategy.
- Reuse a usable token scoped to that connection, audience, permissions, and environment.
- Acquire or renew before expiry using a configurable buffer for clock skew and request duration.
- Coordinate concurrent renewal so several waiting requests do not each rotate the same credential.
- Attach authentication only to the approved downstream request.
- Classify rejected authentication: expired token, revoked grant, insufficient permission, configuration failure, or provider unavailability. Apply a bounded policy.
- Record redacted lifecycle events and mark the connection reconnect-required when unattended renewal is impossible.
The simulation below advances a fictional clock by buttons. It shows one coordinated renewal and failure states without making network calls, accepting secrets, or persisting tokens.
Custom authentication belongs in the profile
Suppose a fictional enterprise API documents POST https://auth.example.com/session/token. Its response contains a token and expires_in in seconds. An illustrative profile can reference credentials, map those fields, constrain the destination, and inject a bearer header. Callers still use invokation.request(...); the auth request and renewal policy live alongside the connection.
A lifetime might instead come from a documented absolute expiry or an appropriate exp claim. Do not invent a lifetime when the contract is unknown. Reading an unverified JWT payload can provide a conservative cache-expiry hint; it does not verify a signature, authenticate an identity, or grant authorization. A JWT has no inherent refresh endpoint. Read the custom token/JWT guide for configuration decisions and the OAuth lifecycle guide for protocol-specific behavior.
Connection health before the next failed customer action
Distinguish usable, expiring, renewing, temporarily unavailable, and reconnect-required states. Show the last successful acquisition, safe expiry metadata, bounded attempt history, and an actionable category. Exclude tokens, passwords, authorization headers, and sensitive auth response fields from payload inspection and alerts.
A token endpoint outage should not start an infinite renewal storm. Honor quotas, isolate affected connections, apply backoff, and fail within a bounded waiting budget. A cached token may only be used while the configured contract still considers it usable.
Renew credentials without repeating business actions blindly
Renewing a token is different from retrying the request that uses it. An ambiguous external write may already have happened. Review the operation’s idempotency policy and destination state before resubmission. No authentication strategy can make arbitrary payments, messages, or record updates universally exactly-once.
Explore the developer design preview, compare connection profiles, or join early access to describe the authentication pattern your team needs. Share categories and constraints only; never paste credentials, actual private endpoints, or token values into research answers.