When implementing native app login with Ory (e.g., in an Android app), the account linking process—especially when a user tries to link a social sign-in (OIDC) account to an existing account that uses a password—follows the same security principles as in browser-based flows. How the password prompt is handled: - If a user tries to sign in with a social provider (e.g., Google) and Ory detects that the email is already associated with an existing account (created with a password), Ory will require the user to confirm ownership of the existing account before linking. This is typically done by prompting the user to enter their password. - In native apps, this prompt is part of the self-service flow. Your app should render the UI for the password prompt using the flow data returned by Ory's API. The user enters their password, and your app submits it to Ory to complete the linking process. - The flow for native apps is similar to browser flows, but uses the

/self-service/{flow_type}/api

endpoints and does not require CSRF tokens. You are responsible for rendering the UI and handling the flow steps as described in the Ory documentation for custom UI integration and native app flows. Key points: - The password prompt is not handled automatically by Ory's UI in native apps; your app must render the prompt based on the flow data. - If the user does not have a password set (e.g., their account was created only with OIDC), and you remove the OIDC provider, the user may be unable to link or recover their account, as there is no credential to verify ownership. This is a known limitation and can result in the user being locked out unless an admin intervenes. It's recommended not to remove OIDC providers that are in use by users without alternative sign-in methods [User account linking](https://www.ory.sh/docs/kratos/social-signin/link-multiple-provider-account), [Github Issue: Account linking prompt](https://github.com/ory/network/issues/400). Summary of the process: 1. User initiates social sign-in in the native app. 2. Ory detects an existing account with the same identifier. 3. Ory returns a flow requiring password confirmation. 4. Your app renders a password prompt UI using the flow data. 5. User enters password; app submits it to Ory to complete linking. If you want to improve the user experience and avoid confusion, consider enabling [login hints](https://www.ory.sh/docs/identities/sign-in/login-hint) to show only relevant authentication methods to the user. If you need to support account linking without a password (e.g., via code sent to email), this is discussed as a possible improvement but is not the default behavior as of now [Github Issue: Account linking prompt](https://github.com/ory/network/issues/400). If you need more details on implementing the native flow, see the [Ory docs on social sign-in for native apps](https://www.ory.sh/docs/kratos/social-signin/native-apps).

import 'package:flutter/material.dart'; import 'package:google_sign_in/google_sign_in.dart'; import 'package:one_of/one_of.dart'; import 'package:ory_client/ory_client.dart'; class SignInWithGoogleButton extends StatelessWidget { final String flowId; final OryClient ory; final GoogleSignIn _googleSignIn = GoogleSignIn( scopes: [ 'email', // Add additional scopes, if you require that data in your Jsonnet mapping ], ); SignInWithGoogleButton({super.key, required this.flowId, required this.ory}); void handleGoogleSignIn(GoogleSignInAccount? value) { value?.authentication.then((value) { var idToken = value.idToken; if (idToken == null) { // If we end up here, but there is no ID token, something went wrong print("No idToken found"); return; } // Create the payload for the updateRegistrationFlow endpoint with the idToken from Google var body = UpdateRegistrationFlowWithOidcMethod( (b) => b ..idToken = idToken ..method = 'oidc' ..provider = 'google', ); // Submit the updateRegistrationFlow endpoint with the payload ory.getFrontendApi().updateRegistrationFlow( flow: flowId, updateRegistrationFlowBody: UpdateRegistrationFlowBody( (b) => b..oneOf = OneOf.fromValue1(value: body)), ); }); } @override Widget build(BuildContext context) { return TextButton( child: const Text("Sign in with Google"), onPressed: () => {_googleSignIn.signIn().then(handleGoogleSignIn)}, ); } }

@chilly-king-10285 I am using ory sdk and google sdk for log in with google. For example: [3:59 PM] import 'package:flutter/material.dart'; import 'package:google_sign_in/google_sign_in.dart'; import 'package:one_of/one_of.dart'; import 'package:ory_client/ory_client.dart'; class SignInWithGoogleButton extends StatelessWidget { final String flowId; final OryClient ory; final GoogleSignIn _googleSignIn = GoogleSignIn( scopes: [ 'email', // Add additional scopes, if you require that data in your Jsonnet mapping ], ); SignInWithGoogleButton({super.key, required this.flowId, required this.ory}); void handleGoogleSignIn(GoogleSignInAccount? value) { value?.authentication.then((value) { var idToken = value.idToken; if (idToken == null) { // If we end up here, but there is no ID token, something went wrong print("No idToken found"); return; } // Create the payload for the updateRegistrationFlow endpoint with the idToken from Google var body = UpdateRegistrationFlowWithOidcMethod( (b) => b ..idToken = idToken ..method = 'oidc' ..provider = 'google', ); // Submit the updateRegistrationFlow endpoint with the payload ory.getFrontendApi().updateRegistrationFlow( flow: flowId, updateRegistrationFlowBody: UpdateRegistrationFlowBody( (b) => b..oneOf = OneOf.fromValue1(value: body)), ); }); } @override Widget build(BuildContext context) { return TextButton( child: const Text("Sign in with Google"), onPressed: () => {_googleSignIn.signIn().then(handleGoogleSignIn)}, ); } } I do not find any password prompt thing here.

New message text here

The

identifiers

field in the

credentials.oidc

schema represents a list of unique identifiers that this OIDC credential matches. For OIDC (such as Google), these identifiers are typically constructed as a combination of the provider and the unique subject identifier from the OIDC provider. For example, for Google, an identifier might look like

google:1234567890

, where

1234567890

is the unique subject (

sub

) claim from the Google ID token [Credentials concept](https://www.ory.sh/docs/kratos/concepts/credentials). How to get this value for Google OIDC: - After a successful Google sign-in, you receive an ID token (JWT). - Decode the ID token and extract the

sub

claim, which is the unique identifier for the user in Google. - The identifier for Ory would then be

google:<sub>

, e.g.,

google:1234567890

. Example:

yaml credentials:   oidc:     id: oidc     identifiers:       - google:1234567890     config:       - provider: google         identifier: 1234567890

[Credentials concept](https://www.ory.sh/docs/kratos/concepts/credentials) --- Can you call the PUT identity API with admin privileges to update credentials without prompting for a password in the account linking flow? The knowledge sources do not explicitly state whether you can bypass the password prompt by directly updating the identity using the admin API. However, the documentation emphasizes that account linking via the self-service flow is designed to ensure the user proves ownership (e.g., by entering a password) when linking accounts with the same identifier. Directly updating credentials via the admin API is technically possible if you have admin privileges, but this approach bypasses the intended security checks and user consent mechanisms of the self-service flow. This could have security implications and is generally not recommended for user-driven account linking [User account linking](https://www.ory.sh/docs/kratos/social-signin/link-multiple-provider-account). Summary: -

identifiers

in

credentials.oidc

is typically

provider:sub

(e.g.,

google:1234567890

). - You get the

sub

value from the Google ID token. - While you can technically update credentials via the admin API, this bypasses the secure, user-driven account linking flow and is not recommended for user-initiated actions. If you need to perform account linking securely, use the self-service flows as described in the Ory documentation.

The subject (

sub

) claim in the ID token from an OpenID Connect provider is intended to be a unique and stable identifier for the user within that provider. According to Ory's documentation, when importing social sign-in connections, the

subject

ID should be the ID of the user on the given platform, and it is usually the

sub

claim of the OpenID Connect ID Token provider such as Google. This suggests that the

sub

value is expected to remain the same for a given user, regardless of how many times you obtain (claim) an ID token from that provider [Social sign-in connections](https://www.ory.sh/docs/kratos/manage-identities/import-user-accounts-identities#social-sign-in-connections). However, the documentation does not explicitly guarantee that all providers will always keep the

sub

value stable under all circumstances (for example, if the user deletes and recreates their account, or if the provider changes their internal policies). For most major providers like Google, the

sub

claim is designed to be stable and unique per user. In summary: For a given user and provider, the

sub

claim in the ID token is generally stable and will be the same each time you obtain an ID token for that user from that provider, as per Ory's documentation and standard OIDC behavior. But the knowledge sources do not provide an absolute guarantee for all providers and all edge cases.

If you bypass the password prompt and use the admin API (such as the PUT identity API) to add credentials directly, the knowledge sources do not describe any mechanism by which a user session is automatically created as a result of this admin action. The admin identity update endpoints are intended for administrative management of identities and do not issue user sessions or authentication tokens as part of their response. Sessions in Ory are created through the self-service login or registration flows, or by using the

session

action/hook after registration. These flows are designed to authenticate the user and then issue a session (via a session cookie or token), which is not the case for admin API calls [Sign in after registration](https://www.ory.sh/docs/actions/session), [Self-service registration/session](https://www.ory.sh/docs/kratos/self-service/flows/user-registration#successful-registration). Summary: - Updating credentials via the admin API does not create a user session. - To obtain a session, the user must complete a self-service login or registration flow, or you must use the appropriate session creation endpoints or hooks. - There is no documented way to create a session for a user as a side effect of an admin credential update. If you need to sign in the user after such an operation, you must trigger a login flow for the user and complete it as usual to obtain a session [Check session status](https://www.ory.sh/docs/identities/sign-in/check-session-token-cookie-api).