Go, ASP.NET, PHP and other backends

There is no dedicated YeboID SDK for these languages in this release. Use an existing OAuth/OIDC client in the application's framework, or generate a wire client from openapi.json. A generated HTTP client does not implement browser-session security or API authorization for you. The platform manifest identifies the available maintained packages.

Sign-in contract

1. Read OIDC discovery, require the configured issuer exactly, and require HTTPS endpoints. The authorization endpoint can have a different origin than the issuer.
2. Bind a cryptographically random state and S256 PKCE verifier to an encrypted server-side browser session. Use an exact registered callback. Request response_type=code and explicit registered scopes, including openid. Send the browser to the discovered authorization endpoint.
3. On callback, atomically consume the pending transaction, verify the exact route, state and a short transaction lifetime, reject duplicate query parameters, and surface denial. Do not exchange a code before these checks.
4. POST a form-encoded authorization-code exchange to the discovered token endpoint. Supply client_id, exact redirect_uri, code and code_verifier; supply client_secret only from a confidential server environment. Do not default to HTTP Basic auth: discovery advertises client_secret_post and none.
5. Persist tokens in encrypted server-side session storage. Fetch profile claims from userinfo using the access token. Store only sub as yeboid_user_id in the product DB.

Protect an API using current token state

Use POST /oauth/introspect with a form body. This works from Go's HTTP client, .NET HttpClient, PHP's HTTP client, or another framework without inventing a local JWT parser:

POST /oauth/introspect HTTP/1.1
Host: api.yeboid.com
Content-Type: application/x-www-form-urlencoded

client_id=YOUR_CLIENT_ID&token=ACCESS_TOKEN&token_type_hint=access_token

A confidential server may also send client_secret in that form. Never print this request body in logs.

Accept the result only when all these conditions hold:

• HTTP success with a well-formed object, active is the boolean true.
• client_id is exactly the client used by your frontend and API.
• token_type is Bearer (case-insensitive). Active refresh-token introspection has no Bearer token type; it must not authorize an API.
• sub is a nonempty string and numeric exp is finite and in the future.
• Required scopes are present in the returned space-separated scope string.

Afterward, check resource ownership in the product API. Return 401 for inactive/invalid tokens, 403 for insufficient permissions, and a normal 5xx error for dependency/network/malformed-response failures. Do not treat an unavailable introspection endpoint as inactive or anonymous success. Use a bounded timeout, reject redirects, and do not automatically retry rotating-token exchanges.

For offline verification, use a maintained JWT library and the discovered JWKS. Require RS256, issuer, audience, expiry, YeboID token-purpose claim type: access, and the actual access-token scopes array. The JWT scopes array differs from the OAuth/introspection wire scope string. ID tokens must not authenticate product API calls. Offline verification cannot see revocation until expiry.

Refresh and sign-out

Serialize the read → refresh → durable-write sequence per session across all server workers. A refresh uses grant_type=refresh_token, client_id and the current refresh_token; omit scope to avoid expanding consent. Persist the rotated refresh token before releasing the lock. If the request result or storage is uncertain, require a new login rather than replaying the old token.

Revoke the current refresh token using /oauth/revoke, then clear the product session only after success. This does not clear the browser SSO cookie or instantly invalidate access JWTs for offline verifiers.

See agent acceptance checks and tokens. Do not claim a dedicated package or a live login until its source/distribution and actual behavior have been verified.