Documentation/Developers
Back
  • Getting started
    • Frontends and app types
    • Environments and endpoints
  • OAuth clients
    • Client ID and secret
    • Redirect URIs and start URL
    • Secret rotation
  • Login with appsolut
    • Authorization code flow
    • Tokens and claims
    • Frontend role
    • Sign-out
    • Revocation and issued tokens
    • Token endpoint errors
  • Frontend keys
    • Issue and store a key
    • Send a key
    • Rotate and revoke
  • Members API
    • Eligibility from a backend
    • The signed-in member
    • Results, rate limits and errors
    • Is an applicant an eligible member?
    • The signed-in frontend user's membership
  • appsolut register API
    • Implement the API
    • Connect and test
    • Verify a member with their challenge code
    • List every member
    • The status of several members
    • The status of one member
    • The person data of several members
    • The person data of one member
    • The claims of several members
    • The claims of one member
    • Health check

OAuth clients

How a frontend gets the OAuth client it signs users in with.

Every frontend is one OAuth client of the Studio's OAuth 2.1 server. The Studio keeps the client for you: there is no separate registration, and the frontend's record in the Studio is the source of truth for it.

When a frontend gets its client

The client is created the first time a Studio user saves the frontend's sign-in settings, on the "Sign-in" card of the frontend's page:

  1. They choose the "App type" ("Web app" today).
  2. They enter the frontend's "Redirect URIs" and its "Start URL" (see Redirect URIs and start URL).
  3. They click "Save sign-in settings".

The Studio then creates the client and shows the dialog "Your frontend's sign-in client" with the client ID and the client secret. The secret is shown this once. Every later save updates the same client; the client ID stays.

Frontend users see the frontend's name on the sign-in surface. There is no separate display name: to change it, the organisation renames the frontend under "Settings".

Who sets it up

Studio users with the Studio role "Owner", "Administrator" or "Frontend manager". As the developer, you provide the redirect URIs and the start URL and receive the client ID and secret, stored straight into your backend's configuration.

Only internal web apps for now

The Studio creates a client only for an internal frontend with the app type "Web app". The Auth server and the sign-in surface refuse every other kind of client, so a confidential client with a backend is the only shape there is today. Public clients (single-page apps, mobile and desktop apps) and external frontends follow later.

In this section

  • Client ID and secret: what each is for and how your backend sends them.
  • Redirect URIs and start URL: the rules for both.
  • Secret rotation: rotating the secret, and recreating a lost client.