Short answer: yes. In self-hosted Ory Hydra, the “login” and “consent” pages are external apps you host and configure via Hydra’s URLs (urls.login, urls.consent). You can point these to any domains you control (including different domains per environment), since Hydra just redirects the user agent to the configured endpoints. In production you typically place Hydra behind a reverse proxy (e.g., Nginx) and set urls.login/urls.consent to your login/consent app’s domain(s). Ensure CORS, cookies, and TLS are configured appropriately on those domains ([Deploy to production](https://www.ory.sh/docs/hydra/self-hosted/deploy-hydra-example), [Install and configure Nginx](https://www.ory.sh/docs/hydra/self-hosted/deploy-hydra-example#install-and-configure-nginx), [Deploy Login & Consent App](https://www.ory.sh/docs/hydra/self-hosted/configure-deploy#deploy-login--consent-app)). Notes and limitations: - Hydra itself uses a single issuer (urls.self.issuer) for a given deployment; make sure this matches the public domain you expose for the OIDC issuer. Your login/consent UIs can live on different domains from the issuer as they are just redirects ([Quickstart](https://www.ory.sh/docs/hydra/self-hosted/quickstart)). - If you need separate brands or multiple login UIs, you can run a login/consent app that routes per requested client/tenant and serves the appropriate domain-specific UI before returning the decision to Hydra ([Kubernetes example with example IDP app](https://www.ory.sh/docs/hydra/self-hosted/kubernetes-helm-chart#exemplary-login-and-consent-app)). - Be mindful that WebAuthn credentials are domain-bound; if your login UI uses passkeys, they will only work on the domain they were registered for ([WebAuthn is not multi-domain capable](https://www.ory.sh/blog/overview-login-password-passkey-webauthn-totp-sso-faceid)).

Short answer: you can host your login UI on any domain(s), but Hydra itself has a single configured login URL at a time. To support multiple domains, front your login app and route per-tenant/domain, or switch the configured login URL per environment. What’s configurable: - Set the login and consent endpoints to your app: urls.login and urls.consent. Hydra redirects users there with a login_challenge/consent_challenge; your app completes the flow and returns the verifier. You can point these to your own domain(s) (e.g., https://login.example.com/login). ([Custom login/consent flow](https://www.ory.sh/docs/oauth2-oidc/custom-login-consent/flow#flow-steps), [Configure Hydra URLs](https://www.ory.sh/docs/hydra/guides/custom-ui-oauth2#configure-ory-network)) How to handle multiple domains: - Run a single login/consent app that serves multiple brands/domains and decides which UI to render based on request host, client_id, or requested audience, then accepts the challenge back to Hydra. Hydra only needs one urls.login; the app can serve many domains. ([Custom login/consent flow](https://www.ory.sh/docs/oauth2-oidc/custom-login-consent/flow)) - Ensure correct CORS and cookie settings on your login/consent app domains. Hydra’s own endpoints support CORS; note /oauth2/auth is not CORS-enabled by design. Configure allowed origins as needed. ([Hydra CORS](https://www.ory.sh/docs/hydra/guides/cors)) Notes: - The issuer in Hydra is single-valued per deployment; use one OIDC issuer while your login/consent UIs can be on different domains since they are just redirects. (Not explicitly stated in sources for multi-issuer; sources only cover redirecting to custom login/consent UIs.) - For Ory Network (managed), you can set custom login/consent URLs similarly; multi-domain per-brand configs are under active work. ([Configure Ory Network](https://www.ory.sh/docs/hydra/guides/custom-ui-oauth2#configure-ory-network), [Per-domain config issue](https://github.com/ory/network/issues/374)) If you need truly separate login URLs per domain at the Hydra config level, the knowledge sources do not describe a built-in per-domain urls.login switch; use an app/router in front to multiplex domains.

Yes, but only if you use the default (built-in) flow; otherwise you must set a login URL. - In self-hosted Hydra, the login endpoint is required: you configure urls.login so Hydra can redirect the user to your app to authenticate, then accept/reject the login challenge. This is the documented model for custom login/consent flows, and examples show urls.login must be set (for example via environment variable URLS_LOGIN) ([Deploy Ory Hydra](https://www.ory.sh/docs/hydra/self-hosted/configure-deploy#deploy-ory-hydra)). - In Ory Network (managed), Hydra is integrated with Ory Identities and the Ory Account Experience by default, so you do not need to implement your own login UI unless you want to customize it. You can override by setting custom login/consent URLs; otherwise the built-in UI is used ([User login and consent flow](https://www.ory.sh/docs/oauth2-oidc/custom-login-consent/flow), [Configure Ory Network](https://www.ory.sh/docs/hydra/guides/custom-ui-oauth2#configure-ory-network)). If you’re self-hosting Hydra alone without Identities, there’s no built-in login UI; you must provide a login URL.

Short answer: yes—your “login URL” does not have to render a UI. It just needs to handle the login_challenge and tell Hydra to accept or reject the login. Details: - Hydra redirects to the configured login endpoint with login_challenge. Your endpoint can programmatically decide the user (e.g., from an existing session, API token, mutual TLS, device SSO) and call acceptOAuth2LoginRequest without showing any page. If skip is true, you should accept immediately and redirect back to Hydra ([Flow steps](https://www.ory.sh/docs/oauth2-oidc/custom-login-consent/flow#flow-steps), [Login endpoint example](https://www.ory.sh/docs/oauth2-oidc/custom-login-consent/flow#login-endpoint-code-example)). - You must still configure urls.login so Hydra knows where to send the user agent; that URL can be an endpoint that always responds with redirects and no HTML UI ([Configure login/consent URLs](https://www.ory.sh/docs/hydra/guides/custom-ui-oauth2#configure-ory-network)). So, a headless/non-UI login handler is supported as long as it processes the challenge and completes the flow via the Hydra API.