Quickstart: managed (sovereign SaaS)

This tutorial takes you from no account to a registered application and a first login on the Thoryn managed service. Thoryn operates the servers; you drive everything through the self-service console and the management API. The whole path is browser-based until the last step.

Time: about 15 minutes. You need: a work email address and a browser. Thoryn provides your website and console URLs when you sign up for the managed service; this guide names the in-product screens rather than hard-coding hostnames.

New to the concepts? A tenant is your isolated slice of the platform (the console calls it your workspace). An application is an OAuth 2.0 / OIDC client — the app that lets its users sign in through Thoryn. You will create one of each below.

Step 1 — Sign up

On the Thoryn website, open Sign up and complete the registration form (name, work email, password). Submitting it creates your Thoryn-managed user account and sends a verification email.

• The website hosts sign-up and password reset only — there is no sign-in form on the marketing site by design. Signing in is a deep-link into the console (Step 2).
• Follow the verification link in the email before continuing.

If you don't receive the email, request a password reset for the same address to re-trigger delivery, then check spam. Reset links are single-use and expire in 15 minutes.

Step 2 — Sign in to the console

Open the console (the website's Sign in action deep-links to it). The console starts the standard OpenID Connect authorization-code flow against the Thoryn hub: you are redirected to sign in, authenticate with the credentials from Step 1, and land back in the console authenticated.

This sign-in is an OIDC login through the hub — you have already exercised the core flow once, as a user of the console itself.

Step 3 — Create your workspace

The first time you sign in, your account has no workspace yet, so the console routes you to onboarding and prompts you to create your workspace. Give it a name; the console provisions your tenant and re-authenticates you into it.

• This is the only place a workspace (tenant) is created — every later configuration step happens inside it, isolated from every other tenant.
• After this step your session carries your new tenant, and the console's configuration surfaces (Applications, Federation, Users, Audit) become available.

Step 4 — Register your first application

In the console, open Applications and Register an application. Provide:

• a display name (for example, My First App);
• one or more redirect URIs — where the hub returns the user after login (for example, https://app.example.com/login/oauth2/code/thoryn, or http://localhost:8080/login/oauth2/code/thoryn for local development);
• a client type — confidential for a server-side app (a secret is minted), or public for a SPA / native app (no secret; PKCE is required);
• the scopes to grant — at least openid, plus profile, email, and offline_access as needed.

On save you receive a clientId, and for a confidential client a clientSecret shown exactly once — copy it now; it is never displayed again (rotate it if you lose it). You can grant a client only scopes you yourself hold, and cross-tenant access to any application always returns 404, never 403.

The console mediates this through the customer-plane management API; the same registration is available directly on POST /api/v1/applications for automation and the thoryn CLI. Full field semantics, client types, and the redirect-URI rules are in Integrate an application → Register an application.

Step 5 — Complete a first login through your app

You now have everything an app needs to sign users in through Thoryn. Drive the flow to see a login complete end to end:

1. Start from discovery. Each tenant is its own OIDC issuer; fetch /.well-known/openid-configuration from your tenant's issuer and use the endpoints it advertises — do not hard-code them.
2. Authorization request → token exchange → UserInfo, using the clientId (and secret, or PKCE code_verifier) from Step 4.

The exact requests, the PKCE parameters, and machine-to-machine (client_credentials) variants are covered step by step in Integrate an application → Run the OIDC Authorization Code + PKCE flow. That guide is the primary integration reference and the natural continuation of this quickstart.

You're set — where to go next

• Integrate an application — the full OAuth / OIDC integration workflow, secret rotation, and troubleshooting.
• Claims in the token — add permissions, org, and org_roles to the ID token your app receives.
• B2B Organizations — model your own business customers as organizations with members and email invitations.
• API reference — the customer-plane management API and its scope catalog, for automating everything you just did in the console.

Troubleshooting

Symptom	Cause / fix
No verification email after sign-up	Check spam; re-trigger by requesting a password reset for the same address. Reset links are single-use and expire in 15 minutes.
The console sends you to onboarding again	You have not created a workspace yet (Step 3), or you signed in with an account that has none — finish the create-workspace step.
clientSecret is missing from the create response	You registered a public client (no secret is minted) — public clients authenticate with PKCE instead.
Lost the clientSecret	It is never re-displayed. Rotate it from the application's page and store the new value.
redirect_uri_mismatch at login	The redirect_uri sent to /oauth2/authorize must match a registered URI exactly (scheme, host, path, trailing slash).
403 scope_not_grantable when registering	You requested a scope you do not hold — a client can be granted only scopes present in your own token.

Security notes

• The website hosts no sign-in form. Credentials are only ever entered on the console's OIDC login path — a deliberate boundary, not an omission.
• Tenant isolation is enforced on every request from the tenant claim in your token; you only ever see your own workspace's data, and cross-tenant access returns 404.
• Client secrets are shown once and stored only as a hash. A lost secret is rotated, not recovered — see the tenant isolation and token security notes.
• Every configuration change writes a tamper-evident audit row in your tenant audit trail.