Scrydon as an Identity Provider
Use Scrydon as an OAuth 2.1 / OIDC identity provider for your own applications — sign users in with their Scrydon account and call Scrydon APIs on their behalf.
Scrydon is a full OAuth 2.1 / OpenID Connect identity provider. Any application you build — internal tools, customer-facing SaaS, AI copilots, mobile apps — can use Scrydon to sign users in and obtain scoped access tokens for Scrydon APIs (workflows, storage, knowledge, and governed LLM completions).
The IdP is exposed on the Identity tab of
Settings → Platform → Identity. That page shows the exact endpoint URLs for
your tenant.
Always copy the endpoint URLs from the Identity tab in the UI. The
hostname is tenant-specific — every deployment declares its own public auth
URL (PUBLIC_AUTH_URL), and the UI renders exactly that value. Typing
hostnames by hand (auth.<tenant>.scrydon.com, api-platform.<tenant>...)
will often hit the wrong host and return 404.
Endpoints
Scrydon implements the standard OIDC / OAuth 2.1 surface. All endpoints live
under /api/auth/ on the auth host.
| Purpose | Path |
|---|---|
| OIDC Discovery | /api/auth/.well-known/openid-configuration |
| JWKS (public signing keys) | /api/auth/.well-known/jwks |
| Authorization | /api/auth/oauth2/authorize |
| Token exchange | /api/auth/oauth2/token |
| Userinfo | /api/auth/oauth2/userinfo |
| Token introspection (RFC 7662) | /api/auth/oauth2/introspect |
| Token revocation (RFC 7009) | /api/auth/oauth2/revoke |
| Dynamic client registration (RFC 7591) | /api/auth/oauth2/register |
Most RP (relying-party) libraries only need the Discovery URL — they fetch everything else from the discovery document.
Supported flows
Scrydon supports the full OAuth 2.1 / OIDC feature set required for enterprise applications:
- Authorization Code + PKCE — recommended for all interactive apps (web, SPA, mobile, CLI).
- Client Credentials — for backend-to-backend automation where no user is present.
- Refresh tokens — long-lived offline access, rotation enforced.
- ID tokens — signed JWTs carrying user identity; decode with the JWKS.
- Custom claims — Scrydon injects tenant / workspace / environment context into ID tokens for the apps you register.
Register an OAuth client (Mini App)
Every application that wants to use Scrydon as an IdP needs a client ID. You create one from the UI — Scrydon calls these Mini Apps:
Open Registered Apps
Navigate to Settings → Organization → Registered Apps and click
Register Mini App.
The list shows 50 apps a page, oldest first; its search box matches app names across every page, not only the one on screen.
Fill in the form
- App Name — any human-readable label.
- Scope — what the client is anchored to:
- Workspace · API access — for apps that call Scrydon APIs on a user's behalf. Pick a workspace; every environment of that workspace gets its own client ID so you can issue separate credentials for dev / staging / prod.
- Organization · SSO only — for pure sign-in (e.g.
gating a site with oauth2-proxy). A
single org-wide client restricted to the identity scopes (
openid,profile,email) — no workspace, no API access.
- Client Type:
- Public · PKCE — SPAs, mobile apps, CLIs. No client secret is issued; the authorization code flow runs with PKCE.
- Confidential · client secret — server-side apps and proxies that can
keep a secret. The
client_secretis shown once after registration and can be rotated later from the app's detail panel.
- Redirect URI — the URL your app receives the authorization code at.
Defaults to
http://localhost:3000/callbackfor local development (required for SSO apps — point it at your gateway's callback). - Allowed Scopes (workspace scope only) — pick what your app is allowed
to request, as
resource:action(read and/or write per resource). Resources:chat,workflows,storage,knowledge,templates,tools,logs(e.g.knowledge:read,workflows:write);:writeimplies:read. You can always requestopenid,profile,emailin addition.
Copy the credentials
For workspace-scoped apps you'll see a client ID per environment — the plugin issues per-environment IDs so a leak in staging can't be replayed against production. Org-scoped SSO apps get a single org-wide client ID.
For confidential clients the client secret is displayed exactly once — copy it now. Scrydon stores only a hash; if the secret is lost, rotate it from the app's detail panel.
Scrydon requires PKCE for every client. SPAs, mobile apps, and CLIs
neither need nor receive a client secret. Choose a confidential client
for server-side apps (oauth2-proxy, backend web apps) that authenticate to
the token endpoint with client_secret_basic — a confidential client sends
PKCE as well as its secret, as OAuth 2.1 recommends (for oauth2-proxy, set
--code-challenge-method=S256). Backend-to-backend automation
without a user can use the client credentials grant; contact support to
enable it on your tenant.
Apps registered before 2026-10-07 are corrected automatically. Until then
Scrydon did not store a registered app's client type: every app was saved
without its token-endpoint authentication method and without its PKCE flag.
The platform upgrade restores both from the app's stored secret — an app with
a client secret becomes confidential (client_secret_basic), an app
without one becomes public — and records PKCE as required for every app,
which is what Scrydon already enforced. You do not need to re-register
anything. One exception: an environment added to a confidential app
before this date was created without a secret. It stays confidential, so
Rotate its secret in the app's detail panel before using it there.