OAuth authorization server
MagOneAI issues its own OAuth 2.1 / OIDC tokens so external clients and MCP servers can authenticate against it
What this is
MagOneAI is not only an OAuth client that signs you in to Google and Microsoft. It is also an OAuth authorization server in its own right: it issues signed access tokens that external clients and MCP servers can verify and act on.
That matters when something outside the platform needs to call in on a user's behalf. An MCP server you host, a desktop client, or an internal tool can run a standard OAuth flow against MagOneAI and receive a token scoped to one audience, instead of you inventing an API-key scheme.
This is a developer-facing surface. If you are looking at who can do what inside the product, you want Access control instead.
Discovery
Everything is discoverable at well-known URLs on your deployment, so a standards-compliant client needs only your base URL.
| Endpoint | What it serves |
|---|---|
/.well-known/openid-configuration | OIDC discovery document |
/.well-known/oauth-authorization-server | RFC 8414 authorization server metadata |
/.well-known/oauth-protected-resource/{server} | RFC 9728 metadata for one resource server |
/.well-known/jwks.json | Public keys for verifying tokens |
The issuer is {your-app-url}/magauth, and the two endpoints a client drives are {issuer}/authorize and {issuer}/token.
All four are public and cached for 5 minutes.
What the server supports
| Response types | code |
| Grant types | authorization_code, refresh_token, client_credentials |
| PKCE | S256, mandatory |
| Client auth | none (public clients), client_secret_post, client_secret_basic |
| Signing algorithm | ES256, per deployment |
| Token format | at+jwt (RFC 9068) |
| Scopes | openid |
| Token claims | sub, iss, aud, exp, iat, org, scope |
PKCE is not optional. An authorization request with no code challenge, or one that is not S256, is refused. This is deliberate: it removes the code-interception attack for public clients rather than leaving it to each client to opt in.
There is no consent screen. The v1 flow is for first-party clients, and the resource owner is the platform user who is already signed in, identified from their existing session.
Audience binding is the point
A token is minted for one audience, requested with the resource parameter (RFC 8707). A resource server accepts only tokens addressed to itself.
This is what stops a token issued for one surface being replayed against another. A token minted for a custom app cannot be presented to the superadmin API, and the rejection needs no database lookup at all: the resource server verifies the signature against the published JWKS, checks the issuer and expiry, and compares the audience. Offline, in memory, on the token alone.
MagOneAI ships a thin verification shim for exactly this, so an MCP server can enforce the audience gate without carrying platform code or database access.
Signing keys
Each deployment holds its own ES256 (P-256) keypair, stored in Vault and cached in process. The public half is published at /.well-known/jwks.json with a key id, so clients verify tokens without ever contacting the platform.
Because the keypair is per deployment, tokens from your staging environment are not valid in production. That is a property worth relying on rather than working around.
Limits in v1
Be aware of these before you build on it:
token-exchangeis not implemented. A request for that grant returns501, not a token.- Refresh tokens cannot be revoked. There is no rotation or revocation list yet, so a leaked refresh token stays valid until it expires. The mitigations are a short refresh lifetime and the per-audience gate. Treat refresh tokens as secrets accordingly.
openidis the only scope. Authorization beyond the audience check is decided by the platform, not carried in the token.