Your own OAuth app

By default the integration provider's shared app runs the consent flow. It works for every toolkit, at a cost: the screen says "Allow <provider> to access Slack" and asks for whatever that shared app was registered with.

For many organizations that is fine. For some, anyone whose security review reads consent screens, it is not.

The distinction that matters

Whose name the consent screen carries is separate from who holds the grant.

Registering your own OAuth app changes the first. The integration provider still holds the resulting grant: credentials are forwarded to it and written to no store here, which keeps the "Memnox stores no provider token" rule intact.

Configuring it

Connectors → Auth config, per toolkit. Five fields, and only the first two change whose name appears on the screen.

Field

Client ID and Client secret

From the app you registered with the tool. Both or neither, setting one alone is a configuration error rather than a partial upgrade. With them, consent names your organization; without them, the shared app is used.

Redirect URI

Where the tool sends the person back. The console shows the value to paste into your app's settings, so it does not have to be assembled by hand.

Auth scheme

How the tool expects to be authenticated. Goes with your own app.

Scopes

What is asked for. Works with or without an app of your own, so you can narrow the shared app's request without registering anything.

User scopes

The grant on the consenting person's own token rather than the bot's. In Slack this is the "perform actions as you" block.

Adding a second toolkit is the same five fields again. Nothing about it is a code change.

When it takes effect

Configuration is applied the first time that toolkit is connected. An existing connection keeps the app it was created under; reconnect to move it.

One thing people get wrong

Choosing scopes

Ask for what ingestion actually needs, which is usually read-only:

Purpose

Reading messages as evidence

History and read scopes on the channels concerned

Reading issues and PRs

Read scopes on the repositories concerned

Executing tools

Write scopes, only if you intend governed tool execution

If you are not executing tools, do not ask for write scopes. The consent screen is read by the person approving it, and an unnecessary write scope is the thing that stalls the approval.

A tool's consent screen showing the organization's own app name and narrowed scopes

screenshot slot, save as public/screens/…png and set src

With your own app registered, the consent screen carries your company's name and asks only for what you configured.

Connecting a toolkit

The flow this configuration changes.

Security posture

What is stored where, across the whole product.