Skip to content

Register an app

A registered app is an application your organization trusts to act for its members: an internal dashboard, a partner’s portal, a script with a web front end. An administrator registers it once and decides what it may do. After that, any member can sign in to it with their Resorcerer account, and the app calls the REST API as that member.

It is the right choice when you build or buy an app and want people to sign in to it rather than paste in an access token. For the other ways in, see Which credential to use.

You need to be an organization administrator.

  1. Open Organization Settings → Registered Apps and choose New Application.
  2. Give it a name your members will recognize, and optionally a description. Both appear on the sign-in screen.
  3. Add one or more redirect URIs. These are the only addresses Resorcerer will send a member back to after they approve the app. Each must use https, or http on your own computer (localhost, 127.0.0.1 or [::1]) while you develop.
  4. Choose whether the app is confidential. Leave it on for an app with a server that can keep a secret. Turn it off for an app that runs entirely in the browser or on a device, which cannot.
  5. Choose the permissions the app needs. They work like an access token’s scope: which areas it can reach, whether it can read or also write, and, for models, whether it can create them or only reach the ones you pick.
  6. Save. Resorcerer shows the app’s client ID and, for a confidential app, its client secret. Copy the secret now. It is shown only once and can’t be retrieved later, only replaced.

The Registered Apps list shows each app’s client ID, whether it is confidential, its permissions, and how many members are currently signed in to it.

When a member signs in to the app, Resorcerer asks them to approve it. The screen names the app, shows its description and the address they’ll be returned to, and lists the permissions the app asked for. A member can approve or cancel, but can’t pick and choose: the app gets exactly the permissions you registered, or nothing.

Only members of your organization can sign in to its apps. Anyone else is told the app belongs to an organization they’re not in, and can’t approve it.

An app never has more access than the member using it. If a member can’t open a private model, neither can the app while it acts for them.

  • Rename it, or change its description or redirect URIs. Everyone stays signed in.
  • Change its permissions. Every member signed in to it is signed out, because they approved a different set. They approve the new permissions the next time they sign in. Resorcerer warns you before saving and tells you how many people were signed out.
  • Rotate its secret (confidential apps). The old secret stops working at once, and the new one is shown once. Update the app before its members’ next sign-in or token refresh fails.
  • Delete it. Every member signed in to it is signed out, and it can no longer sign anyone in. Resorcerer tells you how many sessions that ends before you confirm.

Registered apps use the standard OAuth 2.0 authorization code flow with PKCE, so any OAuth client library will do. The app’s details are published at:

https://app.resorcerer.ai/.well-known/oauth-authorization-server
  1. Send the member to sign in. Open https://app.resorcerer.ai/oauth/authorize with response_type=code, your client_id, one of your registered redirect_uris, a state value, and a PKCE code_challenge with code_challenge_method=S256. PKCE is required, for confidential apps too.
  2. Receive the code. After the member approves, Resorcerer redirects to your redirect_uri with code, your state, and iss (the issuer, so you can check the response came from Resorcerer). If they cancel, you get error=access_denied.
  3. Exchange it for tokens. POST to https://app.resorcerer.ai/api/oauth/token with grant_type=authorization_code, the code, your code_verifier, client_id and redirect_uri. A confidential app also authenticates with its client secret, either as HTTP Basic credentials or as a client_secret form field.
  4. Call the API. Send the access token as Authorization: Bearer <token>. It lasts an hour.
  5. Refresh it. Before it expires, POST the refresh token to the same token endpoint with grant_type=refresh_token and your client_id (and secret, for a confidential app). You get a new access token and a new refresh token; the old refresh token stops working. A member stays signed in as long as the app keeps refreshing, and is signed out after 30 days without use.

An authorization code works once and expires after ten minutes. Store refresh tokens as carefully as passwords, and never reuse one that has already been exchanged. Presenting a used refresh token again signs the member out.

A registered app signs members in. It can’t act on its own with no member present. For that, use a service account.

You want Use
An app your members sign in to, with permissions you control centrally A registered app
An AI assistant connected by one member The MCP connection; the assistant signs itself up the first time it connects
A script or job of your own, acting as you An access token, from My Settings → Access Tokens
An automation that acts as itself, with no member behind it A service account, under Organization Settings → Service Accounts

Members’ access tokens and the AI assistants they’ve connected are listed together on the Access Tokens page, where an administrator can revoke any of them. Sign-ins to registered apps aren’t listed there; you manage them from the app, by changing its permissions or deleting it.