Browser and native sign-in

Public clients cannot protect a shared client secret. Use hosted authorization code flow with PKCE S256. Oathvera currently supports SPA, public web and native client registrations; there is no published Oathvera browser or native SDK in this release.

Browser applications

1. Create a Single-page web or Web with PKCE client.
2. Register the exact callback and browser origin. For example, a local client might use http://localhost:3000/callback and origin http://localhost:3000.
3. Fetch discovery with the client ID query parameter, check its issuer, and configure a compatible OIDC library with the resulting endpoints.
4. Generate state, nonce and PKCE for every attempt. Bind the transaction to the browser session and expire it after at most ten minutes.
5. Redirect to hosted login, then validate callback state and iss, reject duplicate response parameters, and exchange the code once.

Public token exchange uses no Authorization header or client secret:

const response = await fetch(`${issuer}/oauth2/token`, {
  method: 'POST',
  body: new URLSearchParams({
    grant_type: 'authorization_code',
    client_id: clientId,
    code,
    redirect_uri: registeredCallback,
    code_verifier: originalVerifier,
  }),
});

This fragment shows the exchange only. It is not a complete login implementation. Before trusting identity, the library must validate the ID token’s signature through JWKS, expected ES256 algorithm, exact issuer, audience, expiry and saved nonce. Remove the callback’s code from the address bar after processing.

The dashboard’s public PKCE download also returns an expected nonce and leaves ID-token verification to the integrator. Do not use a JWT decoder as verification. If you already have a backend that can manage tokens, the server web reference supplies a complete validated sign-in demonstration.

Keep access tokens in memory. Refresh tokens need special care in browser applications; prefer a server session where practical, and never serialize tokens into shared logs or URLs. Implement one refresh operation at a time. Browser token, revocation and UserInfo access require the registered origin; permission checks belong on your API server and intentionally have no browser CORS interface.

Native applications

1. Register a Mobile or desktop client and an exact supported callback.
2. Use the system browser for hosted sign-in and PKCE; keep the verifier local to the originating transaction.
3. Receive the callback through an appropriately secured HTTPS app link or registered loopback listener. The current implementation does not advertise dynamic loopback-port matching; register and verify the actual callback.
4. Validate the code response and ID token as above. Store renewable credentials using platform-protected storage, and implement local logout plus server revocation.

Custom-scheme callbacks, Device Authorization Grant, embedded password collection and framework-specific native SDKs are outside the current supported contract. A native application that depends on those capabilities needs a separate implementation decision before integration.

Library compatibility checklist

• Code response only, PKCE S256, mandatory state and nonce.
• Exact issuer including its tenant path; ES256 ID tokens and opaque access tokens.
• Only the parameters listed in the HTTP reference. Do not automatically add prompt, max_age, response_mode, audience, organization or other extensions.
• Use resource for API selection. Request only registered identity scopes and explicitly granted permissions.
• Do not assume email/name claims will be returned merely because profile or email was requested.
• Do not assume generic RP-initiated logout options are accepted; use Oathvera’s documented logout fields.

Record the chosen library and version, configuration adaptations and actual acceptance results. Support for an OIDC protocol profile does not establish compatibility with every framework adapter.