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.
Register an app
Section titled “Register an app”You need to be an organization administrator.
- Open Organization Settings → Registered Apps and choose New Application.
- Give it a name your members will recognize, and optionally a description. Both appear on the sign-in screen.
- 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, orhttpon your own computer (localhost,127.0.0.1or[::1]) while you develop. - 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.
- 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.
- 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.
What your members see
Section titled “What your members see”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.
Change, rotate, or remove an app
Section titled “Change, rotate, or remove an app”- 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.
Build the sign-in
Section titled “Build the sign-in”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- Send the member to sign in. Open
https://app.resorcerer.ai/oauth/authorizewithresponse_type=code, yourclient_id, one of your registeredredirect_uris, astatevalue, and a PKCEcode_challengewithcode_challenge_method=S256. PKCE is required, for confidential apps too. - Receive the code. After the member approves, Resorcerer redirects to your
redirect_uriwithcode, yourstate, andiss(the issuer, so you can check the response came from Resorcerer). If they cancel, you geterror=access_denied. - Exchange it for tokens.
POSTtohttps://app.resorcerer.ai/api/oauth/tokenwithgrant_type=authorization_code, thecode, yourcode_verifier,client_idandredirect_uri. A confidential app also authenticates with its client secret, either as HTTP Basic credentials or as aclient_secretform field. - Call the API. Send the access token as
Authorization: Bearer <token>. It lasts an hour. - Refresh it. Before it expires,
POSTthe refresh token to the same token endpoint withgrant_type=refresh_tokenand yourclient_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.
Which credential to use
Section titled “Which credential to use”| 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.
Related
Section titled “Related”- APIs — what the app can call once it has a token.
- Connect AI agents — the same sign-in, for assistants.
- Work with your team — members, tokens and permissions.