> ## 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 > The six ways an app authenticates to a Gateway or Deployment, and who sets each one up. Every app you connect to an MCP Gateway or Deployment authenticates using one of six methods. The app decides which method applies, not you. When you connect it, Airia only asks for the fields that method actually needs. ## The six methods | 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 | A server can support more than one of these methods at once. When it does, you pick which one to use the first time you connect it. ## No Authentication Some servers require no credentials at all. These are usually servers that serve public documentation or data with nothing user-specific to protect. There is 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 it to confirm the key works before you save. * You can 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. If a provider calls this a "Personal Access Token" or "PAT" in its own setup instructions, it is still the same credential type in Airia, under the provider's preferred name. ## 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. An OAuth connection gets established in one of two ways, depending on whether the provider supports automatic registration. ### Dynamic Client Registration (DCR) Most OAuth servers support DCR, meaning Airia registers itself with the provider automatically. There is no setup step for anyone: click **Connect**, sign in with your account on that provider, and you are done. ### Manual Configuration Some providers do not support DCR, or require every customer to register and manage their own application for security reasons. Microsoft Entra ID is a common example, since it does not support DCR at all. For these, an admin registers the application with the provider once, then enters the resulting details into Airia: Follow the server's own connection instructions inside Airia. They tell you exactly what is needed and where to find it in the provider's developer settings. Paste both into Airia. Nobody besides the admin who sets it up ever sees the **Client ID** or **Client Secret**. Airia requests certain scopes by default. Enter values in **OAuth Scopes** only if you want Airia to request other scopes, or the server requires user-specific scopes. Once the registration is in place, everyone else clicks **Connect** and signs in like they would for any other OAuth app. Whether a server uses DCR or Manual Configuration is fixed by that server, not a choice you make while connecting. ## Pass-Through Pass-Through forwards the same credentials you already use to reach Airia straight through to the remote server, without Airia storing anything on your behalf. * There is 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. In practice, Pass-Through is 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. 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 is nothing 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 has not been set up, the option is not 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. ## Related Resources Decide when to share one credential across the org versus per user Approve which catalogue servers your org can connect Choose where to connect an app before you authenticate it Add an app and enter its credentials