Introducing OAuth 2.0 Applications: Secure Sign-In for Your Integrations
We have just shipped a new way to connect integrations to your Federated Directory: OAuth 2.0 Applications. Instead of embedding a static, shared secret in a system, each of your users can now sign in and consent individually — the same way you would "Sign in with Google" or "Sign in with Microsoft" on any other service.
In this article
- Two ways to integrate: API keys and Applications
- What's new: OAuth 2.0 Applications
- How the sign-in flow works
- What access looks like once connected
- Setting it up
- Built on open standards — no custom connectors required
- Why this matters for AI assistants and MCP clients
Two ways to integrate: API keys and Applications
Federated Directory has always let you integrate other services with your data through an API key — a static credential with administrative permissions, ideal for unattended, server-to-server automation. That has not changed, and API keys remain the right choice for those scenarios.
What is new is a second option: an Application, an OAuth 2.0 client used for integrations where an actual person authenticates and consents, instead of a static secret being embedded in a system.
| API key | OAuth 2.0 Application |
|---|---|
| A single, static credential shared by a whole integration | No shared secret — each user authenticates individually |
| Best for unattended, server-to-server automation | Best for interactive clients used directly by your people |
| Access is fixed to the groups you assign to the key | Access is automatically limited to the intersection of the signed-in user's groups and the groups that enabled the application |
| Revoke by deleting or rotating the key | Revoke per user (their consent) or disable the application for a group — nothing to rotate or redistribute |
| A compromised key exposes everything it is scoped to, until it is revoked | Compromise is limited to a single user's own access at a time |
The two methods are not mutually exclusive — a common setup uses an API key for background synchronization and an Application for the interactive tools your team actually signs in to.
What's new: OAuth 2.0 Applications
Registering an Application takes a name, a description, and one or more redirect URIs supplied by the client you are integrating — for example, your AI assistant's or MCP client's OAuth callback URL. Privacy policy, terms of service, and a developer contact email are optional.
Registering an application does not, by itself, grant it access to any data. Access is granted per group: when a group is created, you choose which applications its members may log in with and grant access to that group's data — either specific applications, or all applications, including ones registered in the future.
This means you can register an Application once, well before any group needs to use it, and simply enable it for new groups as they come up — no secrets to copy around, no redeployment required.
How the sign-in flow works
Once an Application is enabled for a group, any member of that group can connect a supporting client and sign in interactively. The client discovers the authorization details automatically from the Federated Directory endpoint, redirects the user to a consent screen, and the user logs in and approves access — no token needs to be copied or configured manually.
The resulting access is automatically limited to the intersection of the groups the signed-in user belongs to and the groups that enabled that application. In other words, a user never sees more through an Application than they could already see themselves in Federated Directory.
What access looks like once connected
Sessions created through the OAuth 2.0 authorization-code flow are automatically issued a dedicated, read-only scope — regardless of the signed-in user's own role in Federated Directory. That scope is intentionally restricted to a small set of read-only endpoints and can never grant admin-level access, even if the signed-in user is an administrator.
In practice, that means an Application can read contact data within its granted groups, but it can never create, modify, or delete anything — not users, not groups, not company settings.
Setting it up
Registering an Application, and assigning it to a group, are both done from the admin portal. Since this is primarily a click-through process rather than an API concept, we keep the full, up-to-date steps in one place rather than duplicating them here:
- Register an Application under Integrations in the admin portal.
- Create or edit a group to choose which Applications its members may sign in with.
- For the technical details behind the flow — audiences, roles, and the dedicated read scope — see the developer documentation.
Built on open standards — no custom connectors required
Applications are not a proprietary bolt-on. They implement the standard OAuth 2.0 authorization-code flow, with the authorization server details discoverable directly from our endpoint. The Federated Directory data itself is exposed through the Model Context Protocol (MCP), an open standard built on JSON-RPC 2.0.
Because both halves of the connection — the sign-in and the data access — follow open, widely adopted standards, any compliant client can connect without us writing a custom integration for it. In practice, that already includes Microsoft Copilot, Anthropic's Claude, OpenAI's ChatGPT, and Google Gemini, alongside self-hosted or open-source models running inside your own infrastructure. A platform we have never heard of, that happens to speak OAuth 2.0 and MCP, works on day one.
Why this matters for AI assistants and MCP clients
The clearest use case today is AI: tools like Claude Desktop, ChatGPT, and other MCP-compatible clients are built to be used directly by a person, not run unattended on a server. Before Applications, giving such a tool access meant distributing an administrative API key to every user who wanted to connect their assistant — a static secret that is hard to scope per person and awkward to revoke.
With an Application, each employee signs in to their own AI assistant with their own identity, and only ever sees the contact data they already have access to. Revoking one person's access never requires rotating a shared secret for everyone else.
That said, Applications are not limited to AI. Any interactive client where a real person is present to authenticate — an internal tool, a partner-facing app, a chat integration — can use the same mechanism. Read the AI integrations page for a deeper look at how this plays out specifically for AI assistants and our MCP endpoint.
Give your integrations secure, user-consented access today — no shared secrets to distribute or revoke.
Explore AI integrations