Third-party OAuth integration
Sign users in with MuoCeon accounts — from registering a client to holding your first token.
This section is for external developers: you own an application (a website, a desktop program, a mobile app, or a server-side service) and want users to sign in with MuoCeon accounts and let you read their identity after consent.
MuoCeon's authorization server implements the standard OAuth 2.0 authorization code flow with PKCE, plus OIDC identity tokens, token revocation and introspection, and standard metadata discovery. There is no proprietary protocol and no custom signing algorithm — any mature OAuth 2.0 / OIDC client library can integrate directly.
Three roles
The integration chain involves three roles. Understand what each one does first, and the rest of the docs will not blur together.
| Role | Address shape | Your relationship to it |
|---|---|---|
| Developer platform | Application entry point | Register your app here and obtain client_id (confidential clients also receive client_secret) |
| Authorization server | {issuer}, e.g. https://id.example.com/v1/oauth | Token exchange, refresh, revocation, introspection, JWKS, metadata |
| Consent UI | {consentUiUrl}/authorize | Where users sign in and confirm authorization; the target of the browser redirect |
The developer platform is not live yet. To create a client, submit the details listed in
Registering a client and redirect URIs and operations
will register it on your behalf; once done you receive the client_id and the effective status of
your redirect URIs.
Capabilities you will use
| Capability | Available to third parties | Notes |
|---|---|---|
| Authorization code + PKCE | ✅ | The only way third parties obtain tokens; S256 required |
| Refresh tokens | ✅ | Issued only when offline_access is requested; rotated on every refresh |
| Token revocation / introspection | ✅ | RFC 7009 / RFC 7662 |
OIDC id_token / UserInfo | ✅ | Issued when openid is requested; profile data comes from UserInfo |
| Metadata discovery | ✅ | RFC 8414 / RFC 9728 / OIDC Discovery |
Step-up authentication (ACR / max_age) | ✅ | You may require stronger authentication |
| Authorization details (RFC 9396) | ⚠️ First-party only | Used for account self-management; not applicable to third parties |
| Token exchange (RFC 8693) | ⚠️ First-party only | Admin console exchanging oauth / account audience tokens |
| Implicit flow / password grant / third-party client credentials | ❌ | Not supported, and not recommended |
Section map
Before you start
Register a client, register redirect URIs, discover metadata, run the minimal flow
Authorization flows
Authorization code + PKCE end to end, exchanging and refreshing tokens, token exchange
Permissions and security
Scopes and audiences, redirect URI policy, step-up, authorization details
Reference
Endpoint list, token structure, error codes
What one authorization looks like
User browser Consent UI (id) Authorization server (server)
│ │ │
│ 1. redirect to /authorize │
├────────────────────>│ │
│ │ 2. session check + pre-validate
│ ├─────────────────────────>│
│ │ 3. render app name and permission list
│ 4. user clicks "Allow" │
│ │ 5. submit authorization decision
│ ├─────────────────────────>│
│ 6. 302 back to redirect_uri │
│<────────────────────── code + state + iss ──────┤
Your backend │ │
├── 7. POST /token (with code_verifier) ─────────>│
│<──────────── access_token / refresh_token ─────┤Steps 2 to 5 all happen inside MuoCeon's own pages and services. You do not implement them, and you cannot replace them — all you control is the redirect parameters in step 1 and the token request in step 7. Details are in Authorization code flow.
Glossary
| Term | Meaning |
|---|---|
issuer | Authorization server identifier; the token's iss must match the metadata's issuer |
client_id | Your registered client identifier — public, safe to appear in browser URLs |
client_secret | Secret for confidential clients; server-side only |
redirect_uri | A registered callback address; must be sent again when exchanging the code |
scope | The permission list, formatted as <resource audience>:<object>:<action> or an OIDC standard value |
aud | Token audience; determines which resource servers accept this token |
acr | Authentication strength level for this session (aal1 / aal2), carried in the token |
state | A random anti-CSRF value you generate and get back verbatim |