OAuth clients
An OAuth client is a registration for one outside integration that signs your members in through Allegro. A partner's mobile app, a companion site, a community platform, a member portal your team runs separately — each gets its own client, its own credentials, and its own allowlists.
Once a client is registered, the integration can send a member to your hosted sign-in page and, when the member signs in, receive a token that acts as that member. Nothing else on your side needs to change: the member's session, profile, and entitlements are the same ones the rest of Allegro sees.
Manage clients from Organization Settings → OAuth Clients.
Register a client
- Go to Organization Settings → OAuth Clients and click Create client.
- Give it a Name that identifies the integration, not the person who asked for it. The name appears on your sign-in page, so members will read it.
- Add each Redirect URI the integration will send members back to.
- Add each Allowed origin, if the integration needs to detect existing sessions. Leave this empty otherwise.
- Leave Require PKCE on unless the integration tells you it cannot support it.
- Click Create client.
Allegro then shows the Client ID and the Client secret. Send both to the integration through a channel you trust.
The client secret is displayed only on the screen that follows creation. Allegro stores a hash of it and cannot show it again. If it is lost, use Regenerate secret — which invalidates the old one and breaks the integration until they deploy the new value.
What each field controls
| Field | What it does |
|---|---|
| Name | Identifies the client in this list, in the Activity Log, and on the sign-in page. |
| Redirect URIs | The only URLs Allegro will send a member back to after they sign in. |
| Allowed origins | The only websites allowed to ask Allegro whether a visitor is already signed in. |
| Require PKCE | Forces the integration to prove, at the end of the flow, that it started the flow. |
| Active | Turns the client off without deleting it. An inactive client cannot start a sign-in. |
Redirect URIs
A redirect URI is where a member's browser goes once they have signed in, and it carries a one-time code the integration exchanges for a token. Allegro will only use a URI on this list, which is what stops someone from crafting a sign-in link that delivers a member's code somewhere you have not approved.
URIs are matched exactly. https://app.acme.com/callback and
https://app.acme.com/callback/ are two different values, and a query string
that differs by one character will not match. Ask the integration for the
precise URL rather than deriving it, and add every environment they need. HTTPS
is required.
Allowed origins
Allowed origins are for a different job than redirect URIs. They control which websites may call Allegro to ask "does this visitor already have a session?" — so the integration can greet a returning member instead of showing a sign-in prompt they do not need. If the integration is not doing that, leave this list empty; a client with no allowed origins cannot make that request at all.
An origin is a scheme, a host, and an optional port, with nothing after it:
https://community.acme.com
Origins are matched exactly, and a wildcard cannot be entered here at all. Add each site individually — one entry per community, property, or subdomain that needs it. A parent domain does not cover the hosts beneath it.
This request reveals whether a particular person is signed in. If Allegro
matched https://*.acme.com, then anyone who took over any one unused subdomain
could ask that question about your members. Exact matching means a compromised
host has to already be on your list.
The same reasoning is why this list is separate from the CORS allowed origins in Browser Settings, which do accept wildcards.
Require PKCE
PKCE is an extra check that ties the end of a sign-in to the beginning of it, so a stolen one-time code cannot be redeemed by whoever stole it. Leave it on.
Turn it off only when an integration tells you it cannot generate the value — typically an older server-side integration that authenticates with its client secret alone. Turning it off weakens that one client and nothing else.
Managing an existing client
Open a client from the list to rename it, change its allowlists, toggle Require PKCE or Active, regenerate its secret, or delete it.
| Action | Effect |
|---|---|
| Save | Applies immediately. A removed redirect URI or origin stops working on the next request. |
| Regenerate secret | Invalidates the current secret at once. The integration is broken until it deploys the new one. |
| Active off | The client can no longer start a sign-in. Tokens it already holds are unaffected. |
| Delete | Permanent. Use Active instead when you may want the integration back. |
Changes to a client are recorded in the Activity Log under the Security category, including the before and after values of the redirect URI list. Secret rotations are logged as an event, but the secret itself is never recorded.
Related
- Sign-in page — Header and footer copy on the page members see
- Branding — The look of the sign-in page
- Activity Log — The record of client changes
- OAuth 2.0 — The developer guide to send your integration partner