I'm sorry, but the knowledge sources do not explicitly mention when Ory updates the identifier type for an identity. The available documentation describes the structure of identity objects, including the presence of identifiers and their types, but does not detail the specific conditions or events under which the identifier type is updated. If you need more precise information about identifier type updates, you may need to consult Ory's official support or community channels.

Ory determines the identity type (e.g., password or OIDC) based on the credentials associated with the identity. Each identity can have multiple credential types, such as

password

or

oidc

, and each credential type has its own set of unique identifiers. For example, an identity might have a password credential with an email identifier and an OIDC credential with a provider-specific identifier. The type is distinguished by the credential type field in the identity object, such as

password

or `oidc`:

yaml credentials:   password:     id: password     identifiers:       - <mailto:john.doe@acme.com|john.doe@acme.com>   oidc:     id: oidc     identifiers:       - google:j8kf7a3...       - facebook:83475891...

When a user logs in, Ory uses the identifier (such as an email or OIDC subject) and matches it against the identifiers stored under each credential type. The credential type that matches determines the authentication method and, by extension, the "type" of login being performed (password or OIDC) [Credentials](https://www.ory.sh/docs/kratos/concepts/credentials). Fixing an identifier to be only OIDC: You can control which identifiers are used for each credential type by configuring your identity schema and registration/login flows. If you want an identifier (such as an email or username) to be used only for OIDC and not for password authentication, you should not mark it as a password identifier in your JSON schema. For example, only add the

"identifier": true

property under the OIDC credential, and not under the password credential in your schema. This way, the identifier will only be valid for OIDC authentication and not for password-based login [Customize identity schemas](https://www.ory.sh/docs/kratos/manage-identities/customize-identity-schema#password-login-identifier). If you do not enable the password method or do not mark any trait as a password identifier, then only OIDC authentication will be possible for that identifier. Summary: - Ory determines the identity type by matching the provided identifier to the credential type (password, OIDC, etc.). - You can restrict an identifier to be used only for OIDC by configuring your identity schema accordingly and not enabling it as a password identifier. If you need more specific configuration examples, let me know!

The knowledge sources do not provide explicit details on how to set an OIDC identifier directly in the identity schema. The available documentation describes how to configure identifiers for password, WebAuthn, code (one-time code), and other credential types using the

<http://ory.sh/kratos|ory.sh/kratos>

extension in the identity schema, but does not mention OIDC identifiers in this context. OIDC credentials and their identifiers (such as the subject from an OIDC provider) are typically managed automatically by Ory Kratos when a user signs in via an OIDC provider. These identifiers are not set through the identity schema, but are instead associated with the identity during the OIDC authentication process [Credentials](https://www.ory.sh/docs/kratos/concepts/credentials). If you need to control or customize OIDC identifiers, you may need to look into Ory's OIDC provider configuration or use the API to manage identities after OIDC login, but this is not covered in the provided knowledge sources.

Based on the knowledge sources, you cannot directly configure an OIDC-only identifier in the identity schema using the

<http://ory.sh/kratos|ory.sh/kratos>

JSON Schema extensions. The identity schema extensions documented are for password, WebAuthn, code, and other credential types, but there is no mention of an OIDC-specific identifier configuration in the schema. OIDC credentials and their identifiers (such as the OIDC subject) are managed by Ory Kratos during the OIDC authentication process, not through the identity schema itself [Customize identity schemas](https://www.ory.sh/docs/kratos/manage-identities/customize-identity-schema#identity-schema-extensions) [Credentials](https://www.ory.sh/docs/kratos/concepts/credentials). If you want an identity to be OIDC-only, you should not mark any trait as a password identifier in your schema and ensure that only OIDC authentication is enabled. However, the actual OIDC identifier (the subject from the OIDC provider) is not set in the identity schema but is handled by Ory during the OIDC login flow. Summary: - There is no way to set an OIDC-only identifier directly in the identity schema. - OIDC identifiers are managed by Ory during the OIDC authentication process, not via the schema. If you need to restrict authentication to OIDC only, configure your flows and schema to not support password or other credential types, but the identifier itself is not schema-configurable for OIDC.

No, you cannot have a user (identity) in Ory Kratos without a Kratos identifier (the internal

id

field). Every identity created in Ory Kratos is assigned a unique internal identifier (

id

), which is a UUID generated by the system and cannot be changed or omitted. This internal identifier is always present and is used by Ory Kratos to reference and manage identities internally [Identity model](https://www.ory.sh/docs/kratos/manage-identities/overview). If you are referring to login identifiers (such as email, username, etc.), those are defined in your identity schema and can be customized, but the internal Kratos

id

is always required and automatically set by the system.

Short answer: - Kratos: No single “authn” endpoint. Authentication is performed via self-service login flows (browser or API) like GET /self-service/login/browser to initialize and then POST to the flow’s ui.action to submit credentials; successful API logins return a session and session_token (used with /sessions/whoami) ([Kratos quickstart](https://www.ory.sh/docs/kratos/quickstart#perform-registration-login-and-logout); [Login API clients](https://www.ory.sh/docs/kratos/self-service/flows/user-login#api-clients); [createBrowserLoginFlow](https://raw.githubusercontent.com/ory/kratos/master/spec/api.json)). - Hydra: Hydra is an OAuth2/OIDC provider. It doesn’t authenticate users itself; it delegates login to your app via the login/consent flow. Your app accepts the login_challenge and calls Hydra’s admin API to accept or reject the login (e.g., PUT /admin/oauth2/auth/requests/login/accept), after which Hydra continues the OAuth2 flow ([acceptOAuth2LoginRequest](https://raw.githubusercontent.com/ory/hydra/master/spec/api.json); [Ecosystem overview](https://www.ory.sh/docs/ecosystem/projects)).

You integrate Hydra (OAuth2/OIDC) with Kratos (identities) by using Hydra’s login/consent flow and delegating user auth to Kratos. High-level steps: - Run both services and configure Hydra to use custom login and consent URLs that point to your app (or to Kratos Account Experience if using Ory Network). Hydra delegates end-user authentication to that login URL via login_challenge. Your app uses Kratos for the actual login UI and session. ([Custom login and consent](https://www.ory.sh/docs/oauth2-oidc/custom-login-consent/flow); [Ecosystem overview](https://www.ory.sh/docs/ecosystem/projects)). - In the OAuth2 flow: 1) Client starts at Hydra /oauth2/auth. 2) Hydra redirects to your configured login URL with login_challenge. 3) Your login app checks if the user has a Kratos session; if not, it initializes Kratos’ login flow and authenticates the user (password or social/oidc). On success, you have a Kratos session. 4) Your app accepts the Hydra login request via Hydra’s admin API and proceeds to consent. 5) After consent handling, Hydra issues tokens and redirects back to the client. ([User login and consent flow](https://www.ory.sh/docs/oauth2-oidc/custom-login-consent/flow)). - If you don’t want to build a custom login/consent app, Ory Network bundles Hydra with Ory Identities and provides a default UI, so you can use it out of the box without wiring the flows yourself ([Introduction to Ory Hydra OAuth2](https://www.ory.sh/docs/oauth2-oidc)). - For social sign-in via Kratos feeding into Hydra SSO, configure Kratos OIDC providers (e.g., GitHub), so the Kratos login can authenticate users who then complete Hydra’s flow ([Login with OIDC providers](https://www.ory.sh/docs/kratos/self-service/flows/user-login#login-with-google-facebook-github--openid-connect--oauth-20)). - Best practice: treat apps like Argo CD or Saleor as OAuth2/OIDC clients of Hydra; keep Hydra as the single provider and register each app as a client with proper redirect URIs; use Authorization Code (+PKCE for public clients); request only needed scopes/claims ([Hydra discussion guidance](https://github.com/ory/hydra/discussions/4023); [Run your own OAuth2 Server](https://www.ory.sh/blog/run-oauth2-server-open-source-api-security)). If you need concrete endpoints and sample code for the login/consent handler, follow the “custom login and consent” guide and the example app hydra-login-consent-node, which shows how to fetch login_challenge, authenticate the user, and accept/reject via the Hydra admin API ([Custom login and consent](https://www.ory.sh/docs/oauth2-oidc/custom-login-consent/flow); [Hydra login/consent example](https://www.ory.sh/blog/run-oauth2-server-open-source-api-security)).

Here’s a concise way to run an API-driven login with Hydra (OAuth2/OIDC) while using Kratos to actually authenticate the user, without rendering browser UIs: High-level flow - Client initiates OAuth2 at Hydra /oauth2/auth (Authorization Code or other flow). Hydra needs a login URL configured to your app (login handler) (Try custom UI; configure URLs) ([Try custom UI: Configure Ory Network](https://www.ory.sh/docs/hydra/guides/custom-ui-oauth2#configure-ory-network)). - Hydra redirects the user agent to your login URL with login_challenge (custom login/consent flow) ([User login and consent flow](https://www.ory.sh/docs/oauth2-oidc/custom-login-consent/flow); [Flow steps](https://www.ory.sh/docs/oauth2-oidc/custom-login-consent/flow#flow-steps)). - Your login API verifies or creates a Kratos session using Kratos’ API flow endpoints (no browser redirects/cookies), then accepts the Hydra login using the challenge. - Hydra proceeds to consent; your API handles consent and accepts/denies; Hydra issues tokens. Concrete steps and endpoints 1) Configure Hydra login/consent URLs to your API - Set oauth2/urls/login and oauth2/urls/consent to your API endpoints (for example, http://localhost:3000/login and /consent). In Ory Network, fetch and patch oauth2-config as shown (then update) ([Configure Ory Network](https://www.ory.sh/docs/hydra/guides/custom-ui-oauth2#configure-ory-network)). 2) Handle Hydra login_challenge in your API - Your POST/GET /login receives ?login_challenge=... - Fetch login request and decide skip or not; accept or reject via Hydra Admin SDK as in the example login handler (acceptOAuth2LoginRequest / rejectOAuth2LoginRequest). On accept, redirect to data.redirect_to returned by Hydra ([Login endpoint code example](https://www.ory.sh/docs/oauth2-oidc/custom-login-consent/flow#login-endpoint-code-example)). 3) Authenticate user with Kratos using API flow (no browser) - Initialize Kratos login API flow: GET /self-service/login/api (returns flow with ui.action) ([API flows overview](https://www.ory.sh/docs/kratos/self-service#api-flows-native-mobile--desktop-apps-command-line-interfaces-smart-tvs-and-more); [Login for API clients](https://www.ory.sh/docs/kratos/self-service/flows/user-login#login-for-api-clients-and-clients-without-browsers); [Create login flow (native/api)](https://www.ory.sh/docs/kratos/bring-your-own-ui/custom-ui-basic-integration#create-login-flow)). - Submit credentials to ui.action with POST application/json (identifier/password or other enabled methods). Successful API login yields a session; for API usage you’ll typically get a session token you can verify with /sessions/whoami (Kratos docs show the pattern for API flows) ([Submit flows](https://www.ory.sh/docs/kratos/bring-your-own-ui/custom-ui-basic-integration#submit-flows); [API flows overview](https://www.ory.sh/docs/kratos/self-service#api-flows-native-mobile--desktop-apps-command-line-interfaces-smart-tvs-and-more)). 4) After successful Kratos auth, accept the Hydra login - Call acceptOAuth2LoginRequest with subject set to the Kratos identity ID, possibly remember/remember_for, then redirect to the provided URL (Hydra continues to consent) ([Login endpoint code example](https://www.ory.sh/docs/oauth2-oidc/custom-login-consent/flow#login-endpoint-code-example); [Flow steps](https://www.ory.sh/docs/oauth2-oidc/custom-login-consent/flow#flow-steps)). 5) Handle consent via API - Your /consent receives consent_challenge. Fetch request; if skip or trusted, accept directly; else present scopes to the client and accept/deny. Example shows building id_token claims from Kratos identity via Identity API before accept ([Consent endpoint code example](https://www.ory.sh/docs/oauth2-oidc/custom-login-consent/flow#consent-endpoint-code-example)). Notes - Do not use Kratos browser endpoints for API-driven apps; use the /api variants to avoid CSRF cookie flows ([API flows overview](https://www.ory.sh/docs/kratos/self-service#api-flows-native-mobile--desktop-apps-command-line-interfaces-smart-tvs-and-more); [Login for API clients](https://www.ory.sh/docs/kratos/self-service/flows/user-login#login-for-api-clients-and-clients-without-browsers)). - A complete working example for Hydra login/consent handlers is available (Node.js) and can be adapted to call Kratos API flows for authentication ([Custom login/consent example](https://www.ory.sh/docs/oauth2-oidc/custom-login-consent/flow); [Flow steps](https://www.ory.sh/docs/oauth2-oidc/custom-login-consent/flow#flow-steps)). Minimal pseudo-sequence - Client → Hydra /oauth2/auth - Hydra → your /login?login_challenge=... - Your API: - Kratos: GET /self-service/login/api → POST credentials to flow.ui.action → session - Hydra: acceptOAuth2LoginRequest(challenge, subject=kratosIdentityId) → redirect_to - Hydra → your /consent?consent_challenge=... - Your API: - Get consent request → accept (possibly build id_token claims from Kratos) → redirect_to - Hydra → client (tokens issued) (Hydra flow details and examples referenced above) ([Flow steps](https://www.ory.sh/docs/oauth2-oidc/custom-login-consent/flow#flow-steps); [Consent example](https://www.ory.sh/docs/oauth2-oidc/custom-login-consent/flow#consent-endpoint-code-example)).

Short answer: Not as a built-in “admin login” that skips user authentication. - Kratos: End-user authentication is done via self-service flows (password, passkey/WebAuthn, code/OTP, OIDC, etc.). These flows explicitly require a user-facing method; there’s no documented API flow that authenticates a user without any factor like a special admin bypass. For API clients you must still use the native (/api) login flow and one of the enabled methods ([Login flow; methods list](https://www.ory.sh/docs/kratos/self-service/flows/user-login), [Browser vs native API flows](https://www.ory.sh/docs/kratos/bring-your-own-ui/custom-ui-basic-integration#flows)). You can disable password and only use methods like passkeys or one-time codes, but not “no-factor” login ([Passwordless options](https://www.ory.sh/docs/identities/get-started/passwordless), [One-time code](https://www.ory.sh/docs/kratos/passwordless/one-time-code)). - Hydra: Hydra does not authenticate end users itself; it delegates to your login app. Your app must authenticate the user before accepting the Hydra login request. There is no Hydra-provided endpoint to “admin-authenticate” a user without any factor in the OAuth2 flow ([Custom login/consent flow](https://www.ory.sh/docs/oauth2-oidc/custom-login-consent/flow)). Admins can programmatically accept login/consent via the Admin API, but your login app would still need to decide the subject—Hydra doesn’t bypass authentication on its own. If you meant service-to-service (machine) auth: that’s done via standard OAuth2 client credentials in Hydra, not by logging in a user; but this is outside the provided sources.

Yes. Ory Kratos supports passwordless authentication methods that create a session without a password: - One-time code (OTP) via email or SMS: enable the code strategy and users authenticate by entering a code sent to their address/number (no password). You must mark the identifier in the identity schema for code (email or sms) when using custom schemas ([Email/SMS one-time code](https://www.ory.sh/docs/kratos/passwordless/one-time-code); [Enable SMS/Email OTP](https://www.ory.sh/docs/kratos/passwordless/one-time-code#enable-sms-one-time-code-otp); [Schema extension for code identifiers](https://www.ory.sh/docs/kratos/manage-identities/customize-identity-schema#passwordless-one-time-code-login-identifier)). - Passkeys (WebAuthn): authenticate users with platform or security keys, no password required. Enable the passkey strategy and, if using a custom schema, set the display_name trait for passkeys ([Passkeys enablement](https://www.ory.sh/docs/kratos/passwordless/passkeys#passkeys-with-the-dedicated-passkey-strategy); [Passkeys overview](https://www.ory.sh/docs/kratos/passwordless/passkeys)). Kratos’ login flow supports these methods alongside others (password, OIDC). You choose which methods are enabled in configuration ([Login methods](https://www.ory.sh/docs/kratos/self-service/flows/user-login)).

Yes. Ory Polis can act as an OIDC client to upstream Identity Providers, and Ory OAuth2/OIDC (Hydra) is OIDC-compliant—so you can register Ory Kratos’ OAuth2/OIDC (via Ory Hydra or Ory Network’s OAuth2) as a “Generic OIDC Provider” in Polis. Configure the provider’s discovery URL, client ID, and secret in Polis as described for OIDC connections and OIDC provider setup ([OIDC Provider setup](https://www.ory.sh/docs/polis/sso-providers/generic-oidc); [Add OIDC connections in Admin Portal](https://www.ory.sh/docs/polis/admin-portal/enterprise-sso#add-oidc-connections); [SSO flow supports OIDC](https://www.ory.sh/docs/polis/sso-flow#openid-connect-flow)).

Partially, but with limitations. - What Polis does: It translates SAML/OIDC SSO from enterprise IdPs into a standard OAuth 2.0/OIDC authorization code flow for your app ([Intro to Polis](https://www.ory.sh/docs/polis); [Example flow](https://www.ory.sh/docs/polis/sso-flow/example-flow); [OIDC flow support](https://www.ory.sh/docs/polis/sso-flow#openid-connect-flow)). Your app (or a gateway) then exchanges the code at Polis’ token endpoint and fetches the user profile from Polis. - Where Hydra fits: Hydra is the OAuth2/OIDC provider in the Ory stack. The provided sources don’t document a direct, supported integration path where Kratos consumes Polis’ OAuth2/OIDC output without Hydra in between. Kratos is an identity server handling its own self-service authentication and can act as an OAuth2 client to upstream IdPs, but the sources here don’t show Kratos ingesting Polis as an OIDC provider or vice versa without Hydra ([Ory components](https://www.ory.sh/docs/intro#components); [Ecosystem overview](https://www.ory.sh/docs/ecosystem/projects)). - What’s certain from docs: Polis can front SAML/OIDC IdPs and expose an OAuth2/OIDC flow to your application. Using Polis alone with your app is supported (service or npm library modes) ([Polis quickstart](https://www.ory.sh/docs/polis/quickstart); [Embedded/OAuth handlers](https://www.ory.sh/docs/polis/guides/npm-library#single-sign-on-authentication)). I’m sorry, but the knowledge sources do not explicitly document a pattern to wire Polis directly to Kratos without Hydra. If your goal is “SSO into my app,” you can integrate Polis directly with the app. If your goal is “central OIDC provider,” that role is covered by Hydra or Ory Network’s OAuth2 component.

I’m sorry, but the knowledge sources do not explicitly state whether Ory Polis implements its own session management. The docs describe Polis as an SSO service that abstracts SAML/OIDC into an OAuth 2.0 flow and outline its authentication options (magic links, email/password, SAML/OIDC SSO) for the Admin Portal, but they don’t detail a standalone session management subsystem beyond using NextAuth in the Admin Portal setup ([Introduction to Ory Polis](https://www.ory.sh/docs/polis) and [Admin Portal authentication methods](https://www.ory.sh/docs/polis/admin-portal#authentication-methods)).

You don’t plug Hydra directly into Kratos. Instead, you run both and wire Hydra’s login/consent to an app that uses Kratos to authenticate the end-user. Flow: 1) OAuth2 client starts authorization at Hydra (/oauth2/auth). 2) Hydra redirects to your Login URL with a login_challenge. 3) Your login app checks/creates a Kratos session (use Kratos self-service login flow), then accepts the Hydra login via Hydra’s Admin API. 4) Your app handles consent similarly, then Hydra issues tokens and redirects back to the client. Key points and docs: - Hydra is the OAuth2/OIDC provider and delegates end-user auth to your app via the Login & Consent flow; Kratos provides the actual user auth and sessions your app relies on ([Ecosystem overview](https://www.ory.sh/docs/ecosystem/projects); [Run your own OAuth2 server](https://www.ory.sh/blog/run-oauth2-server-open-source-api-security)). - In Kratos, use the login flow (browser or API) and enable desired methods (password, OIDC, passkeys, code) ([Login flow and methods](https://www.ory.sh/docs/kratos/self-service/flows/user-login)). - If you want social/OIDC upstreams (e.g., “Sign in with GitHub/Google”) handled by Kratos, enable OIDC in Kratos; Hydra then benefits from that SSO because your login app accepts the Hydra login after Kratos authenticates the user ([Login with OIDC providers](https://www.ory.sh/docs/kratos/self-service/flows/user-login#login-with-google-facebook-github--openid-connect--oauth-20)). If you prefer not to build the login/consent app yourself, Ory Network bundles these (Hydra + Identities + UI) so you don’t need to integrate them manually ([Run your own OAuth2 server](https://www.ory.sh/blog/run-oauth2-server-open-source-api-security)).