Sessions, refresh and credentials

Lifetimes in the current release

Item	Current bound
Pending authorization transaction	10 minutes.
Authorization code	60 seconds, single use.
Human access token / ID token	5 minutes.
M2M access token	5 minutes, additionally limited by current credential and grant authority.
Hosted human session	12-hour idle bound and 7-day absolute bound.
Human refresh family	7-day inactivity and 30-day absolute bounds, also constrained by the associated session and current authority.
New client secret	Default 90 days; configured lifetime 1–365 days.
Credential rotation overlap	Immediate replacement or a bounded overlap of up to 24 hours.

These are current runtime values, not dashboard-adjustable promises for every item. Always honor expires_in and current server decisions. A refresh-family maximum does not extend an expired or revoked session.

Refresh human access tokens

Public clients send their client ID. Confidential clients authenticate with Basic; any redundant body client ID must match.

POST <issuer>/oauth2/token
Content-Type: application/x-www-form-urlencoded

grant_type=refresh_token&client_id=<client-id>&refresh_token=<refresh-token>

For confidential clients, add the Basic header and omit the body client ID if preferred. Optional scope can narrow the newly issued access token below the original grant; it cannot exceed that grant or switch resources. It does not permanently reduce the family’s original scope ceiling. Change the client grant when permanently removing API access. Do not send resource on refresh.

Replace the saved refresh token with the returned token atomically. Serialize refresh per session/family across tabs or server instances. A reused superseded token can revoke the family. If a response is lost after the server may have consumed the token, do not blindly retry it: end the uncertain local session and restart hosted authentication.

The current code exchange returns a refresh token even when offline_access was not requested. Do not treat that as unlimited offline consent or as a durable compatibility promise. It remains subject to session authority, rotation and expiry. M2M has no refresh flow.

Revocation and logout

These operations have distinct purposes:

Operation	What it does
Clear your application’s session	Removes local access. Alone, it does not revoke Oathvera tokens.
POST <issuer>/oauth2/revoke	Revokes the submitted M2M token, or the human grant/refresh family and associated access tokens. Unknown tokens can return 200 without disclosing whether they existed.
GET <issuer>/oidc/logout	Uses the browser’s Oathvera session cookie and an active grant, ends that hosted session and its authority, and redirects to the registered destination.
Console session/user/client changes	Can revoke authority according to the operation’s scope; test affected applications during administrative changes.

Revocation form fields are token and, for public clients, client_id; token_type_hint is optional. Confidential clients require Basic authentication. Keep revocation server-side when the secret is involved.

Hosted logout accepts only client_id and post_logout_redirect_uri. It does not currently accept id_token_hint, state, arbitrary return destinations or upstream-provider logout options. It requires an active hosted session/grant. Calling revocation first can remove the grant it needs; do not assume a subsequent hosted-logout redirect will succeed.

For the provided server example, the chosen behavior is server-side revocation plus clearing the application’s cookie. If you need hosted logout, design and test that separate browser transition using the registered destination. Neither path promises SAML SLO, social-provider logout or global logout across all identity providers.

Signed ID tokens already issued expire normally; local JWT validation alone cannot see revocation. Online access-token checks enforce current authority. Keep your application’s local session lifetime and authorization behavior consistent with that distinction.

Server applications can use GET /oidc/session for a profile-free online check on protected requests. Require the current issuer, client, subject and expiry to match the local session. This retains online revocation enforcement; an unavailable provider denies access instead of using a cached successful check. Fetch UserInfo when profile claims are required, such as the initial verified-email account binding.

Rotate a confidential or service credential

1. Locate the exact client under the application. Record its existing credential expiry and consumers.
2. Choose immediate replacement or the smallest required overlap. At most two credentials can remain active during the permitted overlap.
3. Copy the new secret once into the consuming service’s protected configuration, preserving the client ID and issuer.
4. Validate new token exchange, refresh where applicable, and API checks with the new secret.
5. Finish the handover and revoke the old credential. Verify the expected denial afterward.

M2M tokens issued through an expired or revoked credential stop passing current-authority checks. Human authorization can refresh using a new active credential when the old credential merely expires; explicit credential revocation or immediate replacement has stronger invalidation behavior. Test this distinction for a credential rollout; do not assume all token families behave like M2M tokens.

If the displayed secret is lost, create/rotate a credential rather than searching for a readback API. If a secret is exposed, replace it and verify revocation of affected authority. Do not paste credentials or complete token responses into support reports.