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

Client ID and secret

What the client ID and the client secret are for, and how your backend sends them.

Client ID

The "Client ID" is not secret. The frontend's "Sign-in" card shows it at any time, with a "Copy" button. You send it:

  • as client_id in the authorize request the browser makes;
  • with the client secret when your backend exchanges a code or refreshes a token;
  • as client_id to the sign-out page.

It is also how you recognise your own tokens: every access token carries the client_id it was issued to, and your backend must check it (see Tokens and claims).

Client secret

The "Client secret" proves to the token endpoint that the request comes from your backend. The Studio shows it once, when the client is created and at each rotation, and does not keep it. Copy it into your backend's secret store before you close the dialog with "I have stored the secret". If you lose it, have the secret rotated.

Send it only to POST <auth>/oauth/token, and only with HTTP Basic authentication (client_secret_basic), the method the client is registered with:

POST <auth>/oauth/token
Authorization: Basic base64(<client ID>:<client secret>)
apikey: <publishable key>
Content-Type: application/x-www-form-urlencoded

A secret in the form body is refused, although discovery lists client_secret_post.

Public and confidential clients

OAuth knows two kinds of client. A confidential client has a backend that can keep a secret; a public client (a single-page, mobile or desktop app) cannot, and proves itself with PKCE alone. Every frontend that can sign users in today is a web app, so a confidential client: it uses both the client secret and PKCE. Public clients follow later.

Not the frontend key

The client secret is only for the token endpoint. Calls to the Members API authenticate with the frontend's frontend key, a separate secret issued on the "Keys" card (see Frontend keys).