Skip to content

Forbidden Origin

URI: https://docs.ankatech.co/errors/forbidden-origin
HTTP Status: 403 Forbidden

When you see this

A sign-in request came from a web origin that is not one of the deployment's Management origins. The console is served on the Management origin: the Management host name (https://admin-<env>.<domain> by default, or the name chosen when the environment was created) and, when the environment owns the host's IP address, https://<host-ip>. The sign-in endpoint, POST /api/v3/auth/authorize-challenge, and the passkey registration start of the security self-service answer only a request whose Origin header is exactly one of those origins (scheme, host and port).

A sign-in is also bound to the Management origin it started on: a later step of the same sign-in sent from the other Management origin is refused with this type, and the sign-in is not consumed.

Nothing was started. No sign-in session (auth_session) was created, no credential was examined and no lockout attempt was counted.

The check stops another site from driving a person's browser through the sign-in steps. It is not what makes a passkey phishing-resistant: every passkey ceremony is also bound to the Management host name by the browser and verified by the platform, so an assertion obtained on another host is refused whatever the Origin header says.

Common Causes

  • The console page was opened on the Runtime host (https://<env>.<domain>), which serves workloads and never the console. The Runtime host answers /admin/ with 404.
  • A page hosted on another domain, or a development server on another port, calls the sign-in endpoint directly.
  • The deployment is reached under a name it is not configured with (an internal alias, or a former Management host name after envctl.sh <env> set-management-host).
  • A sign-in started on the Management host name was continued on the IP origin, or the other way round.
  • A non-browser client calls the endpoint without an Origin header, or with another value. The interactive sign-in is for the console; automation uses the token endpoint's grants.

Response Example

{
  "type": "https://docs.ankatech.co/errors/forbidden-origin",
  "title": "Forbidden Origin",
  "status": 403,
  "detail": "Sign-in requests are accepted only from the origin this service is published on.",
  "instance": "/api/v3/auth/authorize-challenge",
  "timestamp": 1792236600
}

Content-Type: application/problem+json — the response follows RFC 9457 Problem Details. This is an Auth API body, so it carries no correlation member: correlate through the X-Correlation-Id response header. See Error Index & Overview.

How to Resolve

  1. Open the console on the deployment's Management host name and sign in from there; start a new sign-in rather than continuing one begun on another origin.
  2. If the console itself is refused, the Management origins the deployment is configured with (MANAGEMENT_PUBLIC_ORIGINS) do not match the address the browser uses. Ask the platform operator to check them; the host name is changed with envctl.sh <env> set-management-host.

For full schema definitions, examples, and interactive testing, see the Developer Hub Reference.