Register your website
Install OAuth from the Znosin app catalog, open My sites and add your website. Each account can own up to 20 integrations. For an organization, use a dedicated owner account, set a password and review its devices.
Website with a server
A confidential client uses client_secret_basic. Save the Client Secret in a server-side secret store: it is shown only once.
Browser application
A public client uses authentication method none and has no Client Secret. Keep the PKCE verifier and tokens out of URLs and logs.
Register up to 10 exact redirect URLs. HTTPS is required; HTTP is allowed only for localhost, 127.0.0.1 or [::1]. Wildcards, fragments and URL credentials are rejected. Keep development and production integrations separate when possible.
Client ID is public. Client Secret rotation immediately invalidates the old secret, codes and access tokens. Changing redirect URLs or disabling a client also revokes existing grants. Never put secrets in Git, frontend code or screenshots.
Configure your OIDC library
| Setting | Value |
|---|---|
| Issuer | https://znosin.com |
| Discovery | https://znosin.com/.well-known/openid-configuration |
| Authorization flow | authorization_code · response_type=code · response_mode=query |
| Scopes | openid profile email |
| PKCE | S256, required for both client types |
| ID-token signature | RS256; public keys from the discovery document’s jwks_uri |
Before redirecting, generate independent, cryptographically random state, nonce and code_verifier. Save them in the visitor’s server session, or browser session for a public client. State and nonce must be 16–512 characters; use at least 32 random bytes. The verifier is 43–128 unreserved ASCII characters. Never reuse a flow.
GET https://znosin.com/authorize?
client_id=YOUR_CLIENT_ID&
redirect_uri=EXACT_REGISTERED_URL&
response_type=code&scope=openid%20profile%20email&
state=RANDOM_STATE&nonce=RANDOM_NONCE&
code_challenge=BASE64URL_SHA256_VERIFIER&
code_challenge_method=S256URL-encode every parameter value. openid is required. Optional prompt=consent is supported. Silent login, forced reauthentication with max_age, request objects and other response modes are not supported.
Handle the callback
- Consume the session’s flow once. Check the original
state, an unexpired flow and an exactissmatch with the issuer. Handleerror=access_deniedwithout creating a session. Never use an untrusted callback parameter as a destination URL. - Exchange the code within 60 seconds using POST form data at
/oauth/token. Sendgrant_type,client_id,redirect_uri,codeandcode_verifier. A code works once. Confidential clients must also use HTTP Basic: form-encode Client ID and Client Secret separately, join with a colon, then Base64-encode. A secret in the request body is not accepted. - Use your OIDC library to verify the ID token’s RS256 signature, exact issuer, audience, expiration, issued-at and session-bound nonce. Check
azptoo if present. Decoding the JWT alone is not verification. - Find or create a local user by the pair
iss+sub, then regenerate your local session ID. Nickname, display name and email can change; they are not identity keys.
POST https://znosin.com/oauth/token
Content-Type: application/x-www-form-urlencoded
Authorization: Basic BASE64_FORM_ENCODED_ID_AND_SECRET
grant_type=authorization_code&
client_id=YOUR_CLIENT_ID&
redirect_uri=EXACT_REGISTERED_URL&
code=AUTHORIZATION_CODE&
code_verifier=ORIGINAL_VERIFIERThe example uses placeholders, not real credentials. For a public client, omit the Authorization header. Both client types must send the original PKCE verifier and exact registered redirect URL. Form-encode all body values.
Profile and permissions
The response contains an ID token valid for 5 minutes and an opaque access token valid for 1 hour. Request /oauth/userinfo with Authorization: Bearer ACCESS_TOKEN. Its sub must match the verified ID token.
| Scope | Returned claims |
|---|---|
openid | sub |
profile | name, preferred_username, picture (public avatar URL) |
email | email, email_verified |
email_verified is currently false. Mailbox provisioning is not an email-ownership verification challenge. Never automatically link an unverified email to an existing password or other-provider account. Require sign-in to the existing account before linking.
Passwords, chats, mail contents, files and agent permissions are not shared. Users can revoke access in Profile → Granted website access. Revocation blocks UserInfo and new token exchanges, but cannot end a website’s own session or invalidate an already issued, offline-verifiable ID token. Your website controls its sessions and logout.
Operations and limits
Public-client CORS allows only exact registered redirect origins. Confidential code exchanges run server-to-server. Never forward the Basic header to JWKS, UserInfo or redirects. Store only the access you need, redact codes and tokens from logs, and rate-limit your callback. Token endpoint limits apply per IP; handle HTTP 429 using Retry-After.
Management requires the owner’s authenticated Znosin browser session and Origin checks. Agent tokens cannot register sites or approve access. Registration is self-service through the OAuth app, not unauthenticated dynamic client registration. The site name is supplied by its owner, not a verification badge; consent shows the actual redirect origin.
This provider implements a bounded OIDC code-flow profile and has not undergone OpenID conformance certification. Refresh tokens, federated logout, PAR, DPoP and automatic RSA key rotation are not implemented. Existing public clients remain supported.