OIDC Discovery & Endpoints
ZewstID is a fully OpenID Connect-compliant identity provider. Any standards-based OIDC client library can integrate by pointing at the discovery URL — there is no custom SDK requirement.
Discovery URL
https://api.zewstid.com/.well-known/openid-configuration
Hit this URL with any OIDC client (NextAuth, Auth.js, jose, oauth2-proxy, AWS Cognito federation, openid-client, etc.) and every other endpoint, the JWKS, supported scopes, response types, and grant types are auto-discovered.
The doc is cached at the edge for 5 minutes; the underlying configuration is stable, so you can also cache it locally for an hour or longer.
Example response
{ "issuer": "https://auth.zewstid.com/realms/zewstid", "authorization_endpoint": "https://api.zewstid.com/oauth/authorize", "token_endpoint": "https://api.zewstid.com/oauth/token", "userinfo_endpoint": "https://api.zewstid.com/oauth/userinfo", "introspection_endpoint": "https://api.zewstid.com/oauth/introspect", "revocation_endpoint": "https://api.zewstid.com/oauth/revoke", "end_session_endpoint": "https://api.zewstid.com/oauth/logout", "jwks_uri": "https://api.zewstid.com/.well-known/jwks.json", "response_types_supported": ["code", "id_token", "token id_token", "code id_token", "code id_token token"], "grant_types_supported": ["authorization_code", "refresh_token", "client_credentials"], "code_challenge_methods_supported": ["S256"], "token_endpoint_auth_methods_supported": ["client_secret_post", "client_secret_basic", "private_key_jwt"], "subject_types_supported": ["public"], "id_token_signing_alg_values_supported": ["RS256"] }
The
field deliberately keeps theissuersuffix because the/realms/zewstidclaim in every token is set by the upstream identity service to that value. Your token verifier must checkiss— not the discovery doc URL.iss === "https://auth.zewstid.com/realms/zewstid"
Endpoints
| Endpoint | Method | Purpose |
|---|---|---|
/.well-known/openid-configuration | GET | OIDC discovery |
/.well-known/jwks.json | GET | JSON Web Key Set for verifying token signatures |
/oauth/authorize | GET / POST | Authorization Code flow entry point (browser-facing) |
/oauth/token | POST | Exchange code → tokens; refresh tokens; client credentials |
/oauth/userinfo | GET / POST | OIDC UserInfo (returns standard claims for the bearer's sub |
/oauth/introspect | POST | RFC 7662 token introspection (resource servers) |
/oauth/revoke | POST | RFC 7009 token revocation |
/oauth/logout | GET / POST | RP-Initiated Logout |
All endpoints are also available at the realm-prefixed paths (
/realms/zewstid/protocol/openid-connect/...JWKS — verifying tokens
GET https://api.zewstid.com/.well-known/jwks.json
Tokens are RS256-signed. Use any JWT library that supports JWKS rotation:
import { createRemoteJWKSet, jwtVerify } from 'jose'; const JWKS = createRemoteJWKSet(new URL('https://api.zewstid.com/.well-known/jwks.json')); export async function verify(token: string) { const { payload } = await jwtVerify(token, JWKS, { issuer: 'https://auth.zewstid.com/realms/zewstid', audience: '<your-client-id>', }); return payload; }
The JWKS endpoint sets
Cache-ControlIssuer vs. discovery URL — read this once
OIDC has two related-but-distinct URLs that beginners often conflate:
- Discovery URL: where the metadata document lives. ZewstID serves it at .
https://api.zewstid.com/.well-known/openid-configuration - Issuer: the value of the claim in tokens. ZewstID's issuer is
iss.https://auth.zewstid.com/realms/zewstid
Most client libraries take an issuer value and append
/.well-known/openid-configuration- If the library lets you set the discovery URL directly, use .
https://api.zewstid.com/.well-known/openid-configuration - If the library only takes the issuer, set it to — the upstream Keycloak realm serves the same doc at
https://auth.zewstid.com/realms/zewstid.<issuer>/.well-known/openid-configuration
Both work. The clean aliases at
api.zewstid.comPKCE is required
Every OAuth client at ZewstID is configured with PKCE (S256) required at registration time. Authorization requests without
code_challengecode_challenge_method=S256invalid_requestSee also
- OAuth Integration Guide — full Authorization Code flow walkthrough
- Scopes Catalog
- Refresh Tokens
- API Keys
Was this page helpful?
Let us know how we can improve our documentation