> ## Documentation Index
> Fetch the complete documentation index at: https://explore.airia.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Supported Credential Types

Every app you connect to an MCP Gateway or Deployment authenticates using one of six methods. Which one applies is decided by the app itself, not something you choose when connecting, so you'll only ever be asked for the fields that method actually needs.

## No Authentication

Some servers, usually ones serving public documentation or data with nothing user-specific to protect, don't require any credentials at all. There's nothing to configure. The app is connected the moment you add it to a Gateway or Deployment.

## API Key

* Paste in your key or token. Airia stores it and attaches it to every request made to that server on your behalf.
* Some servers that use API key auth have a **Test Connection** button. Use **Test Connection** to confirm the key actually works before you save.
* You have the option to share a single key across your whole organization instead of asking every user to generate their own. See [Tenant vs. Personal Level App Credentials](/mcps/admin-controls/tenant-vs-personal-app-credentials) for how that sharing works.

<Tip>
  If a provider's own setup instructions call this a "Personal Access Token" or "PAT" rather than an API key, it's still the same credential type in Airia, just under the provider's preferred name for it.
</Tip>

## OAuth 2.0

The standard method for apps where you sign in with your own account, like Slack, Google Drive, or Salesforce. Your personal sign-in always stays yours, even when the underlying connection to the provider is shared across your organization. See [Tenant vs. Personal Level App Credentials](/mcps/admin-controls/tenant-vs-personal-app-credentials) for that distinction.

There are two ways an OAuth connection gets established, and which one a given server uses depends on whether the provider supports automatic registration.

### Dynamic Client Registration (DCR)

Most OAuth servers support DCR, meaning Airia can register itself with the provider automatically. There's no setup step for anyone: click **Connect**, sign in with your account on that provider, and you're done.

### Manual Configuration

Some providers don't support DCR, or ask every customer to register and manage their own application for security reasons. Microsoft Entra ID is a common example, since it doesn't support DCR at all.

For these, an admin has to register the application with the provider once, then enter the resulting details into Airia:

* **Client ID**.
* **Client Secret**.
* Airia asks for certain scopes by default. If you want Airia to ask for other scopes, or the server itself requires user specific scopes, enter them in **OAuth Scopes**.

A server's own connection instructions inside Airia will tell you exactly what's needed and where to find it in the provider's own developer settings. Once the registration is in place, everyone else just clicks **Connect** and signs in like they would for any other OAuth app. Nobody besides the admin who set it up ever sees the Client ID or Secret.

<Note>
  Whether a server uses DCR or Manual Configuration is fixed by that server, not a choice you make while connecting.
</Note>

## Pass-Through

Pass-through forwards the same credentials you're already using to reach Airia straight through to the remote server, without Airia storing anything on your behalf.

* There's nothing to configure. If your existing sign-in to Airia is accepted by the remote server, the connection works right away.
* Because nothing is stored, this only works when the way you authenticate to Airia and the way the remote server expects to be authenticated line up with each other. In practice, this means Pass-Through is generally limited to servers built specifically to work alongside Airia, rather than general-purpose third-party services.

## Token Exchange

Token Exchange also asks nothing of you directly, but instead of forwarding your credential as-is like Pass-Through does, Airia exchanges your existing Airia sign-in for an access token the remote server accepts.

* There's nothing for you to enter beyond, occasionally, picking which exchange to use if more than one is available for that server.
* This depends on your organization already signing into Airia through an identity provider the remote server also trusts, and on an admin having set up that exchange ahead of time. If it hasn't been set up, this option won't be usable yet, ask your admin to configure it first.
* Microsoft Graph is currently the only example: if your organization signs into Airia with Microsoft Entra ID, Token Exchange lets you use Microsoft Graph with that same sign-in instead of authenticating to Microsoft a second time.

## At a Glance

| Type                  | What you provide          | Set up by                                                            |
| --------------------- | ------------------------- | -------------------------------------------------------------------- |
| **No Authentication** | Nothing                   | Nobody, it connects automatically                                    |
| **API Key**           | A key or token            | You, or an admin sharing one for the whole tenant                    |
| **OAuth (DCR)**       | Just your sign-in         | You, automatically                                                   |
| **OAuth (Manual)**    | Your sign-in, after setup | An admin registers the app once, then everyone signs in individually |
| **Pass-Through**      | Nothing                   | Nobody, it reuses your existing Airia sign-in                        |
| **Token Exchange**    | Nothing                   | An admin configures the exchange once, then it works for everyone    |

<Note>
  A server can support more than one of these methods at once. When it does, you'll get to pick which one to use the first time you connect it.
</Note>