To add Google as a social sign-in provider in Ory Kratos (self-hosted), you need to configure the OIDC provider in your Kratos configuration file. Here’s an example of how the provider configuration should look:

yaml selfservice:   methods:     oidc:       config:         providers:           - id: google # This is <social-signin-provider-id> in the callback URL             provider: google             client_id: <YOUR_GOOGLE_CLIENT_ID>             client_secret: <YOUR_GOOGLE_CLIENT_SECRET>             issuer_url: <https://accounts.google.com>             mapper_url: "base64://{YOUR_BASE64_ENCODED_JSONNET_HERE}" # Or provide a URL/file path             scope:               - openid               - email               - profile       enabled: true

- The

id

field is used in the callback URL and should not be changed once set. - The

client_id

and

client_secret

are obtained from your Google Cloud Console OAuth client. - The

issuer_url

for Google is

<https://accounts.google.com>

. - The

mapper_url

should point to your Base64-encoded Jsonnet mapping file or a URL/file path accessible by Kratos. - The

scope

array should include at least

openid

,

email

, and

profile

for a basic setup. Redirect URI: When registering your OAuth client in Google Cloud Console, set the redirect URI to:

http(s)://<domain-of-ory-kratos>:<public-port>/self-service/methods/oidc/callback/google

Note: If you want users to be automatically logged in after sign-up, add the

session

hook to your registration flow:

yaml selfservice:   flows:     registration:       after:         oidc:           hooks:             - hook: session

For more details and advanced configuration, refer to the official documentation: [Ory Kratos OIDC Configuration](https://www.ory.sh/docs/self-hosted/kratos/configuration/oidc)<source>https://www.ory.sh/docs/self-hosted/kratos/configuration/oidc&lt;/source>.

To add a mapper in Ory Kratos Self-Hosted, you need to create a Jsonnet code snippet that maps the claims from your OIDC provider to your identity schema. Then, you reference this mapper in your Kratos configuration using the

mapper_url

field. Steps: 1. Write your Jsonnet data mapper The mapper should return an object with the structure:

jsonnet    {      identity: {        traits: {          // Map claims to traits here          email: std.extVar('claims').email,          // Add more mappings as needed        },      },    }

The

claims

variable contains all the data sent by the upstream provider. For example, to map Google claims:

jsonnet    local claims = { email_verified: false } + std.extVar('claims');     {      identity: {        traits: {          [if 'email' in claims && claims.email_verified then 'email' else null]: claims.email,          first_name: claims.given_name,          last_name: claims.family_name,        },      },    }

[See more details and examples](https://www.ory.sh/docs/kratos/social-signin/data-mapping#write-a-jsonnet-data-mapper)<source>https://www.ory.sh/docs/kratos/social-signin/data-mapping#write-a-jsonnet-data-mapper&lt;/source>. 2. Encode the Jsonnet file in Base64 Use a command like:

cat your-data-mapping.jsonnet | base64

[Reference](https://www.ory.sh/docs/kratos/social-signin/google#data-mapping)<source>https://www.ory.sh/docs/kratos/social-signin/google#data-mapping&lt;/source>. 3. Add the mapper to your Kratos config In your Kratos configuration file, set the

mapper_url

to the Base64-encoded string:

yaml    selfservice:      methods:        oidc:          config:            providers:              - id: google                provider: google                client_id: <YOUR_CLIENT_ID>                client_secret: <YOUR_CLIENT_SECRET>                issuer_url: <https://accounts.google.com>                mapper_url: "base64://<YOUR_BASE64_ENCODED_JSONNET_HERE>"                scope:                  - openid                  - email                  - profile          enabled: true

Alternatively, you can provide a file path or URL to the Jsonnet file if preferred. Summary: - Write a Jsonnet mapper. - Encode it in Base64 (or provide a file/URL). - Reference it in your Kratos config under

mapper_url

. For more details, see the official documentation: [Self-hosted Kratos OIDC Configuration](https://www.ory.sh/docs/self-hosted/kratos/configuration/oidc)<source>https://www.ory.sh/docs/self-hosted/kratos/configuration/oidc&lt;/source>.

You cannot set the Google

prompt

parameter statically in the Ory Kratos configuration file. Instead, the

prompt

option (such as

none

,

select_account

, or

consent

) must be passed dynamically from your application's UI when initiating a login, registration, or settings flow. To do this, include the

upstream_parameters.prompt

field in the form body when submitting to the Ory flow endpoint. For example, in your login form:

html <form action="https://$<http://PROJECT_SLUG.projects.oryapis.com/self-service/login?flow=<flow-id|PROJECT_SLUG.projects.oryapis.com/self-service/login?flow=<flow-id>>" method="POST">   <input type="submit" name="provider" value="google" />   <input type="hidden" name="upstream_parameters.prompt" value="select_account" /> </form>

Supported parameters for Google include

login_hint

,

hd

, and

prompt

. This approach allows you to control the prompt behavior per request, rather than globally in the configuration. For more details, see the [Ory documentation on advanced UI integration and upstream provider parameters](https://www.ory.sh/docs/kratos/bring-your-own-ui/custom-ui-advanced-integration#login) and [Google provider additional parameters](https://www.ory.sh/docs/kratos/social-signin/google#additional-parameters)<source>https://www.ory.sh/docs/kratos/bring-your-own-ui/custom-ui-advanced-integration#login&lt;/source&gt;&lt;source&gt;https://www.ory.sh/docs/kratos/social-signin/google#additional-parameters&lt;/source>. Summary: - The

prompt

parameter is not set in the static config. - Pass it dynamically as

upstream_parameters.prompt

in your form POST to Ory.

The error

oauth2: "invalid_grant" "Bad Request"

after being redirected from Google (OIDC provider) typically indicates an issue with the OAuth2 flow, often related to the redirect URI or client configuration. Based on the knowledge sources, here are the most common causes and troubleshooting steps: 1. Redirect URI Mismatch Ensure that the

redirect_uri

parameter in your request exactly matches the one registered in your Google OAuth client and in your Ory Kratos configuration. Even small differences (such as a missing slash or query parameter) will cause this error. - The redirect URI should follow this pattern for self-hosted Ory Kratos:

http(s)://<domain-of-ory-kratos>:<public-port>/self-service/methods/oidc/callback/google

- Double-check that this URI is registered in the Google Cloud Console and matches what Ory is using in the flow [See: Social sign-in troubleshooting – redirect_uri mismatch](https://www.ory.sh/docs/troubleshooting/troubleshooting-social-sign-in#redirect_uri-mismatch)<source>https://www.ory.sh/docs/troubleshooting/troubleshooting-social-sign-in#redirect_uri-mismatch&lt;/source>. 2. Authorized Redirect URI Domain If you are using Ory Network, you cannot use the default

<http://oryapis.com|oryapis.com>

domain as the authorized redirect URI with some providers (including Google). You must use a custom domain and configure it both in Ory and in your Google OAuth client settings [See: 'oryapis.com' doesn't work as authorized redirect URI](https://www.ory.sh/docs/troubleshooting/troubleshooting-social-sign-in#oryapiscom-doesnt-work-as-authorized-redirect-uri)<source>https://www.ory.sh/docs/troubleshooting/troubleshooting-social-sign-in#oryapiscom-doesnt-work-as-authorized-redirect-uri&lt;/source>. 3. Client ID/Secret Issues Make sure the Client ID and Client Secret in your Ory Kratos configuration match those from your Google Cloud Console. 4. Other Common Issues - If you recently changed your configuration, ensure you restarted Ory Kratos so the changes take effect. - If you are using a custom domain, ensure DNS and SSL are set up correctly. If you have checked all of the above and the issue persists, review the full error message from Google (if available) for more details, and ensure your Ory and Google configurations are in sync. For further troubleshooting, refer to the [Ory social sign-in troubleshooting guide](https://www.ory.sh/docs/troubleshooting/troubleshooting-social-sign-in)<source>https://www.ory.sh/docs/troubleshooting/troubleshooting-social-sign-in&lt;/source>. If you need to see the exact redirect URI Ory expects, you can copy it from the Ory Console under Authentication → Social Sign-In after selecting your provider.

Yes, it is possible to provide a custom

redirect_uri

(often referred to as

return_to

) when initializing a registration or login flow in Ory Kratos. You do this by appending the

?return_to=<your-url>

query parameter to the endpoint that initializes the flow. For example:

/self-service/login/browser?return_to=<https://myapp.com/protected>

or

/self-service/registration/browser?return_to=<https://myapp.com/welcome>

This will cause Ory to redirect the user to the specified URL after the flow is successfully completed. Note that the domain you use in

return_to

must be whitelisted in your Ory configuration under

selfservice.allowed_return_urls

to prevent open redirect attacks. However, this

return_to

parameter must be set when initializing the flow. If the user switches between flows (e.g., from login to registration), the

return_to

parameter does not automatically persist and must be manually carried over to the new flow if you want the redirect to remain consistent. This is a common pattern for advanced integrations and is documented in the Ory Kratos advanced UI integration guide [Advanced integration](https://www.ory.sh/docs/kratos/bring-your-own-ui/custom-ui-advanced-integration#advanced-redirects)<source>https://www.ory.sh/docs/kratos/bring-your-own-ui/custom-ui-advanced-integration#advanced-redirects&lt;/source>. Summary: - You can provide a custom redirect URI using the

return_to

parameter when starting a flow. - The domain must be whitelisted in your configuration. - The parameter does not persist across different flows unless you manually transfer it. There is no evidence in the knowledge sources that you can override the

redirect_uri

for the OIDC provider itself per flow; the

return_to

parameter controls where Ory redirects the user after the flow, not the OIDC provider's callback.

The

self_service_flow_return_to_forbidden

error occurs when the URL you provide in the

return_to

parameter is not included in the allow list of return URLs in your Ory Kratos configuration. To allow multiple return URLs, you need to add them to the

selfservice.allowed_return_urls

section of your Kratos configuration. Here’s how you can do it:

yaml selfservice:   allowed_return_urls:     - <https://www.myapp.com/>     - <https://anotherapp.com/>     - <https://sub.domain.myapp.com/only/path>

Each URL you want to allow must be listed here. The

return_to

parameter will only work for URLs that match one of the entries in this list. Remember, the match must include the protocol and domain, and for path-specific entries, the path must also match exactly [see Concepts: Browser redirects and flow completion](https://www.ory.sh/docs/concepts/redirects)<source>https://www.ory.sh/docs/concepts/redirects&lt;/source>. After updating your configuration, restart Ory Kratos for the changes to take effect. If you still encounter issues, double-check that the exact URL you are using in

return_to

matches one of the allowed URLs, including protocol, domain, and path if specified.