# 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[​](#register-a-client "Direct link to Register a client")

1. Go to **Organization Settings → OAuth Clients** and click **Create client**.
2. 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.
3. Add each **Redirect URI** the integration will send members back to.
4. Add each **Allowed origin**, if the integration needs to detect existing sessions. Leave this empty otherwise.
5. Leave **Require PKCE** on unless the integration tells you it cannot support it.
6. Click **Create client**.

Allegro then shows the **Client ID** and the **Client secret**. Send both to the integration through a channel you trust.

The secret is shown once

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[​](#what-each-field-controls "Direct link to What each field controls")

| Field               | What it does                                                                                                                 |
| ------------------- | ---------------------------------------------------------------------------------------------------------------------------- |
| **Name**            | Identifies the client in this list, in the [Activity Log](/product/administration/activity-log.md), 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[​](#redirect-uris "Direct link to 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 "Direct link to 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:

```text
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.

Never try to cover a family of subdomains

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](/developer/administration/browser-settings.md), which do accept wildcards.

### Require PKCE[​](#require-pkce "Direct link to 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[​](#managing-an-existing-client "Direct link to 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](/product/administration/activity-log.md) 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[​](#related "Direct link to Related")

* [Sign-in page](/product/administration/sign-in-page.md) — Header and footer copy on the page members see
* [Branding](/product/administration/branding.md) — The look of the sign-in page
* [Activity Log](/product/administration/activity-log.md) — The record of client changes
* [OAuth 2.0](/developer/guides/oauth.md) — The developer guide to send your integration partner