Feature Request: Pass ui_locales to external OIDC identity provider in New Customer Accounts

Authentication & Access
1

Summary

When using an external OIDC identity provider with New Customer Accounts,
Shopify does not pass the ui_locales parameter in the /authorize request.
This makes it impossible for the identity provider to display the login screen
in the correct language based on the store’s current locale.

Current Behavior

  • Store URL includes locale info: https://shopify.com/{shop_id}/account?locale=en&region_country=US
  • Shopify redirects to the external IdP’s /authorize endpoint
  • The ui_locales parameter is not included in the authorize request
  • The IdP has no way to know which language the store is currently displaying

Expected Behavior

Shopify should forward the store’s current locale as the ui_locales parameter
in the OIDC /authorize request, as defined in
OpenID Connect Core Section 3.1.2.1:

ui_locales - OPTIONAL. End-User’s preferred languages for the User Interface.

For example:
/authorize?client_id=xxx&...&ui_locales=en

Use Case

We operate a multi-language Shopify store (Japanese + English) with a custom
OIDC identity provider for LINE Login. When a customer visits the English version
of the store and clicks “Login”, the login screen should appear in English.
Currently, the IdP can only fall back to the browser’s Accept-Language header,
which may not match the store language the customer was browsing.

Context

  • Shopify already supports locale and region_country parameters for
    market-aware auth URLs in headless storefronts
  • The same capability should be extended to external OIDC identity providers
    for non-headless stores
  • ui_locales is a standard OIDC parameter, so this would be spec-compliant

Environment

  • Shopify Plus
  • New Customer Accounts with external OIDC identity provider
  • Multi-market store (Japanese + English)
Feature Request: Pass locale parameter to external OIDC Identity Provider during Customer Account login
2

Hey @user319 - thanks for flagging this. I can’t guarantee anything, but I will get this logged as a feature request on our end for sure. I did do a little digging around to see if I could find a workaround and it does appear that external IdPs can only fall back to Accept-Language headers, so this is fair feedback, thanks again!

1 Like
4

@Alan_G

Thanks! This feature is really important for my clients so I hope it will be added recently!

1 Like