Authorization and security model

Learn how API Gateway authorizes MCP Clients and controls access to MCP Servers.

All MCP access through API Gateway is governed by OAuth 2.1 and a per-client allow list. This authorization model applies to all MCP Clients, including external clients such as Kiro, Claude Desktop, and Cursor, as well as Infor GenAI Agents.

OAuth 2.1 with PKCE

MCP Client Authorized Apps are OAuth 2.1 public clients that authenticate by using the authorization code flow with Proof Key for Code Exchange (PKCE). Because they are public clients, they do not use a client secret. This is the standard authentication flow for interactive clients that cannot securely store a client secret.

Per-client access control

Each MCP Client is restricted to the MCP Servers that are selected when the authorized application is created.

  • An MCP Client Authorized App can be associated with up to 10 individually selected MCP Servers. This limit applies only to MCP Client Authorized Apps. Infor GenAI Agents are not subject to this restriction.
  • The access list is encoded in the OAuth token as the allowed_mcp_servers claim.
  • The gateway validates every MCP request against this list.
  • If a client attempts to access an MCP Server that it is not authorized to use, the gateway returns HTTP 403.
  • Administrators can update the list of allowed MCP Servers at any time by editing the authorized application.

Authentication flow

When an MCP Client calls an MCP Server for the first time, or after its access token expires, this authentication flow occurs:

  1. The MCP Client sends a request to the MCP Server URL.
  2. The gateway returns HTTP 401 with a WWW-Authenticate header that contains the Protected Resource Metadata URL.
  3. The MCP Client retrieves the .well-known/oauth-protected-resource/{path} document to discover the authorization server.
  4. The MCP Client redirects the user to the Infor sign-in page.
  5. The user authenticates and grants consent.
  6. The MCP Client receives an access token that is scoped to the allowed MCP Servers.
  7. Subsequent tool calls use the access token until it expires.
  8. When the token expires, the client uses a refresh token, if one was issued, or prompts the user to authenticate again.

Authorization errors

These authorization errors can occur when an MCP Client attempts to access an MCP Server:

  • HTTP 401: No access token is provided or the access token has expired. The gateway returns a WWW-Authenticate header that contains the resource metadata URL for OAuth discovery.
  • HTTP 403: The client is authenticated but is not authorized to access the requested MCP Server. The gateway returns an MCP-compliant error with the PERMISSION_DENIED error code.
  • HTTP 403: The client is authenticated but does not have the required scope. The gateway returns a WWW-Authenticate header with error="insufficient_scope".

For the complete error response formats, see Error handling.