Gateway access and sign-in

Choose Who can use it on a gateway’s page. The same choices appear under API access on an agent’s page.

• Only you: you, signed in to almyty.
• One team: members of the team you choose, signed in to almyty.
• Everyone in the organization: people in your organization, signed in to almyty.
• Outside, open: anyone on the internet, without a key or sign-in.
• Outside, protected: anyone who can use one of the sign-in methods you allow.

New gateways start with internal access. Opening one to the internet takes an explicit choice and save. An open endpoint cannot run scripts through code mode. These choices control calls to the endpoint; Who can manage it, under the gateway’s settings, controls access to its configuration in almyty.

Allow outside access

Choose Outside, protected and click Save access. For an agent, click Save API access instead. Then switch on any combination of these methods:

A caller only needs one enabled method. Turning off a method stops it working while keeping its settings. Access stays closed until at least one method is ready.

Give out keys

Switch on Keys, click New key, give it a Name and optionally an Expires on date, then click Make key. Copy the key immediately: it is shown once. The list shows its name, last-used date and expiry. Revoke stops a key working immediately.

For example, give a partner’s system one key and an overnight job another. You can revoke the partner’s key without interrupting the job.

Manage usernames

Switch on Usernames and passwords. Add a username and password for each person or system you want to allow, then save the list. Edit the method to add or remove usernames or change a password. Leaving an existing password blank keeps it.

Set up company sign-in

Switch on Company sign-in, choose your provider and enter the client ID and client secret for the sign-in application you registered there. Microsoft also needs your directory ID or verified domain; Okta and Auth0 need the issuer address from your provider.

Under Advanced, copy the Callback address and register it with your provider. The secret is kept in Credentials and is never shown again.

You can limit access to Allowed email domains, Allowed groups, or both. Separate entries with commas. Google domain restrictions check the verified Workspace domain. Microsoft needs a verified domain-owner claim configured for the application.

For Google groups, use group email addresses or IDs, choose a Google Directory credential and enter a Delegated administrator email. The service account needs Workspace domain-wide delegation for https://www.googleapis.com/auth/admin.directory.group.member.readonly. You can create the credential inline; its key stays in Credentials. almyty checks membership through Google Directory and denies access if the check fails.

Microsoft, Okta and Auth0 must include group names or IDs in the signed token when you restrict by group; Advanced lets you name the groups claim. Configure the provider to return that claim. Microsoft group overage without the required group claim does not grant access.

People then use their company’s sign-in in a browser. They do not need an almyty account. Compatible MCP clients start the sign-in flow when they connect.

Use tokens from your own system

Switch on Tokens from your own system and open Advanced. Enter the exact Issuer, the HTTPS Signing keys address (your JSON Web Key Set) and the expected Audience. Save the method. almyty checks the token’s signature, expiry, issuer and audience before allowing a call.

For developers

Request credentials

Managed passwords are bcrypt hashes. The API never returns passwords or password hashes. A saved company client secret is held in the credential vault; reads report whether one is saved.

Enforcement

Endpoint access is independent of management visibility. accessScope and accessTeamId are the gateway’s endpoint policy; an agent API target uses the same policy. Private, team and organization scopes require an almyty identity in the organization and check that scope. Stale outside keys cannot override an internal scope. Open access is explicit. Protected outside access tries the active methods and succeeds when one matches.

The tools and agents published outside still obey their publication checks. Opening a gateway does not expose private or team resources hidden behind it.

OAuth 2.1 (MCP OAuth)

almyty runs an OAuth 2.1 authorization server per the MCP specification:

• Authorization code flow with PKCE (S256 required)
• Client ID Metadata Documents (MCP 2025-11-25): no registration step
• Dynamic Client Registration (RFC 7591): deprecated in MCP 2026-07-28 and kept for clients without metadata-document support; metadata documents come first
• iss in every authorization response (RFC 9207)
• Token revocation (RFC 7009)
• Authorization Server Metadata (RFC 8414)
• Protected Resource Metadata (RFC 9728)

MCP clients handle the flow themselves. On a 401 the gateway returns a WWW-Authenticate header pointing at the protected resource metadata; a compatible client finds the authorization server, identifies itself, runs the code exchange and attaches the token.

https://api.almyty.com/acme/petstore/.well-known/oauth-authorization-server
https://api.almyty.com/acme/petstore/.well-known/oauth-protected-resource

How a client identifies itself. The metadata advertises both ways, in the order the specification asks clients to try them:

1. Client ID Metadata Document (client_id_metadata_document_supported: true). The client uses an https URL as its client_id, for example https://app.example.com/oauth/client.json. almyty fetches that document, checks that its client_id is exactly that URL, that it names client_name and redirect_uris, and that the redirect_uri of the request is one of them. Only public clients (token_endpoint_auth_method: none) are accepted. The consent screen shows the client’s name and the host of its URL, because the name is the client’s own claim. The client is stored once, keyed by its URL, so codes, tokens and revocation work as for a registered client, on any gateway.
2. Dynamic Client Registration. Deprecated in MCP 2026-07-28 and kept for clients that need it. A registration may name application_type: web needs https redirect URIs (loopback http only outside production), native may use loopback http on any port or a private-use scheme such as cursor://. A registration without it whose redirect URIs are all loopback is taken as native, since that is what CLIs and desktop apps send; set MCP_OAUTH_INFER_APPLICATION_TYPE=false for the plain OIDC default (web). The response echoes application_type.

The metadata document is fetched through the same guard as every other outbound request (no private, loopback or cloud-metadata addresses, no redirects, a total deadline and a size cap), with nothing relaxed for self-hosted installs. Fetches are limited per host, and a document is cached for its Cache-Control lifetime within bounds. All of it is configuration:

A gateway owner can accept registered clients only by setting "oauth": { "clientMetadataDocuments": false } in the gateway’s configuration; the gateway’s metadata then stops advertising the option.

iss. Every authorization response, approval or denial, carries iss set to the gateway’s issuer (https://api.almyty.com/acme/petstore), and the metadata says so with authorization_response_iss_parameter_supported: true.

Refresh tokens rotate on use. Revoking a refresh token also revokes its access tokens.

Scopes. An OAuth token carries the scopes the user approved on the consent screen: mcp:tools, mcp:resources, mcp:prompts or mcp:*. On an MCP gateway, tools/* methods need mcp:tools, resources/* need mcp:resources and prompts/* need mcp:prompts; a UTCP gateway needs mcp:tools for every call. A missing scope is a 403 insufficient_scope naming the scope. API keys and the other methods are not scope-checked.

Validation rules

An auth method can carry extra checks. Restrict by IP range:

{
  "validationRules": {
    "allowedIpRanges": ["10.0.0.0/8", "192.168.1.100"]
  }
}

Or require headers:

{
  "validationRules": {
    "requiredHeaders": ["X-Request-Id", "X-Client-Version"]
  }
}

Several methods

Outside protected methods are alternatives: one successful enabled method allows the request. Disabling or reconfiguring company sign-in also ends the validity of tokens issued under its previous settings.