Skip to main content

OAuth Clients

OAuth clients make Autessa an OAuth 2.0 provider for your own applications. Register a client, point your app at Autessa's hosted sign-in page, and users authenticate with their Autessa account — your app receives access and refresh tokens without ever handling their password.

What it's for​

API keys and poweruser keys authenticate you; an OAuth client authenticates your users. If you're building an external product — a companion mobile app, a partner portal, a browser extension — that needs to know which Autessa user is on the other end, register it as an OAuth client. Autessa hosts the sign-in screen (email/password or Google), validates your client and redirect URI, and hands your app a token pair for that user.

For how OAuth tokens fit alongside API keys and poweruser keys — and which credential each part of the API reference expects — see Authentication.

Open API Management → OAuth Clients in the sidebar. The page lists your registered clients in a table — client name, copyable client ID, redirect URIs, an Approved/Pending status badge, and creation date — with Edit, Rotate Secret (confidential clients only), and Delete actions per row, and a Register OAuth Client button at the top.

Key concepts​

  • Public vs. confidential — chosen at registration and not editable afterwards. Public (SPA / Browser Extension) clients get no secret — suitable for code that runs where a secret can't be kept. Confidential (Server-side) clients receive a client secret, shown once at creation, that must accompany token and refresh requests. Only confidential clients can rotate their secret.
  • Redirect URIs — a comma-separated list of allowed callback URLs, each starting with http:// or https://. At sign-in time the requested redirect_uri must exactly match a registered one — no wildcards or prefix matching.
  • Admin approval — new clients start as Pending and must be approved by an Autessa platform administrator before general use. While pending, only you (the creator) can sign in through the client — enough to build and test — and other users are told the application hasn't been approved for public use.
  • The hosted sign-in page — your app sends users to Autessa's /oauth/login page with your client_id and redirect_uri. The page shows "Sign in to connect <your client's name>", offers Google and email/password sign-in, and on success redirects back to your URI with access_token, refresh_token, expires_in, and token_type in the URL fragment. There is no scope picker — a token represents the signed-in user's identity, full stop.
  • Token lifetimes — access tokens live 24 hours; refresh tokens live 7 days and rotate on every refresh. Refresh (/user/oauth/refresh) is bound to the issuing client — confidential clients must present their secret again — and sign-out revokes the refresh token via /user/oauth/revoke.

How to register a client​

  1. On the OAuth Clients page, click Register OAuth Client.
  2. Enter a Client Name — this is what users see on the sign-in screen, so name it after your application.
  3. Pick the Client Type: Public (SPA / Browser Extension) or Confidential (Server-side).
  4. Enter the Redirect URIs your app will use, comma-separated.
  5. Click Register Client. The success modal shows your client ID and — for confidential clients — the client secret with the warning "Save this secret now. It will not be shown again."
  6. If the modal notes the client is pending admin approval, you can test it with your own account immediately; wait for approval before rolling out to other users.

How to rotate a confidential client's secret​

  1. Click Rotate Secret on the client's row.
  2. Confirm — the current secret is invalidated immediately, and any application still using it loses access until updated.
  3. Copy the new secret from the modal; like the original, it's shown only once.

Editing a client (Edit) can change its name and redirect URIs, but not its type. Delete permanently retires the client — irreversible, and any application using it loses access.

Tokens are delivered to your redirect URI in the URL fragment, so register exact, HTTPS callback URLs you control. Treat a confidential client's secret like any server credential — never ship it in frontend code.