Connect salesforce and shopify with shopify standard OIDC function

Hi All,

I’m currently testing Shopify’s OIDC functionality, with Salesforce as the identity provider (IdP) and Shopify as the service provider (SP).

The flow proceeds as expected up to the authorization step:
Shopify successfully call the Salesforce authorization endpoint, the end user logs in and grants access, and Salesforce then redirects back to the specified callback URL with the code and state parameters.

However, Shopify responds with a 401 Unauthorized error at this point, and the logs contain the message:

Something went wrong: Access token request error

This seems misleading, since (to my understanding) shopify should not be requesting an access token at this callback stage—only the authorization code is involved here.

I’ve double-checked the configurations on both the IdP and SP sides, and everything appears to be in order. Btw, I’ve reached out to support, but did not receive any useful information.

Has anyone encountered a similar issue, or could suggest what might be causing this unauthorized response?

Thanks in advance for your help!

Request

GET 
https://{mydomain}.my.salesforce.com/services/oauth2/authorize?scope=openid+email&client_id={clientId}&response_type=code&redirect_uri=https://shopify.com/authentication/{mystore}/login/external/callback&state=01JXVAWTN32D9ZS8X9YCC48SBB&nonce=57826e03-ca27-45d3-9649-6697db6d4ece&prompt

→ Response 302 Found

Request

GET
https://shopify.com/authentication/{mystore}/login/external/callback?code={HereIsACode}&state=01JXVAWTN32D9ZS8X9YCC48SBB

→ Response 401 Unauthorized

Here are some config screen shot:




Hey @Eason_Sun :waving_hand: I believe the “Access token request error” message there is actually accurate.

After receiving an authorization code, Shopify will then attempt to go back to your Salesforce server exchange it for an access token with Salesforce’s token endpoint (a bit more info here). This does seem to be the correct behaviour from what I can tell.

The most common causes for this error are generally mismatched client credentials (client_id/client_secret) between what’s configured in Shopify and Salesforce, redirect URI mismatches (even small differences like trailing slashes can cause this), or expired/invalid authorization codes since they’re typically single-use and expire within minutes.

If you have access to them, I’d recommend checking your Salesforce’s OAuth logs for more specific error details and testing the token exchange manually using cURL to isolate whether the issue is with Shopify’s request or Salesforce’s configuration.

I’m not super familiar with Salesforce, but once thing that might help would be to verify if switching on PKCE (Proof Key for Code Exchange) might help resolve things, as this is a common reason for auth failures. I did a little bit of digging and it looks like this might be something you can set up via Salesforce directly (I saw it as a checkbox selection in your screenshots there too): Help And Training Community

If that doesn’t resolve the issue, I think reaching out to Salesforce may be the best bet since from what I can tell that 401 message is coming from their side after we send out the token request.

Hope this helps a bit - let me know if I can clarify anything on my end here.

1 Like

Hey @Eason_Sun
Salesforce as IDP with shopify with shopify standard OIDC .
↑I also encountered the same issue. Is there a solution?

Hi @TonyKukoc , unfortunately, we are still facing the issue. We log a case to Shopify support and are waiting for the response.

But we do have some further update:

We wrote an Apex REST class with a doGet function and customized the authorize endpoint, token endpoint, and userInfo endpoint in the discovery document. The purpose was to capture debug logs and monitor how Shopify sends requests to Salesforce.

We observed that Shopify did call the authorize endpoint and made a POST request to the token endpoint, but it did not make a request to the userInfo endpoint. We suspect that an error occurred on Shopify’s side while verifying the Id_token. Therefore, we contacted Shopify support to ask whether they could check the error logs on their end.

If there are any updates from support, I will update in this thread~~

1 Like

I am experiencing the same issue, but I am attempting to connect SAP CIAM. Shopify retrieves the token correctly and then simply stops without indicating what the problem is.

I have also opened a ticket and am currently awaiting a response. I have attempted to adjust all possible parameters, but without success…

Hi folks,

Thanks for the debugging work on this and for reaching back out. Your findings about Shopify not calling the userInfo endpoint is really helpful, it seems like the id_token verification may be failing in this circumstance.

I’m happy to help troubleshoot further here in the thread, but if you’d prefer to wait for a response from support directly, that’s definitely fine too.

If you want to dig deeper while waiting, the most helpful thing would be to capture the id_token from your Apex endpoint response. You can decode it safely at jwt.io and check that it contains all required OIDC claims (iss, sub, aud, exp, iat). The aud (audience) claim is particularly important, could you share what that field’s value is if possible? My understanding is that this should match the Shopify OIDC client on our end, so I’m wondering if that could potentially be related to the issue here.

Can you access your discovery document’s jwks_uri endpoint as well? That’s where the public keys for token verification come from. Sometimes accessibility issues there can cause validation failures.

One other thing, I wanted to mention, did you get a chance to try enabling PKCE as we looked into earlier? Still curious if that makes any difference.

Hope to hear from you soon!

I’m experiencing the same as people are describing here.
In my case I have Drupal implementation with a the simple_oauth Drupal module.
I can go through the auth flow fine in https://openidconnect.net/ playground but shopify fails without much info when I click on “test connection”.

I checked thoroughly that all claims required are included in the JWT and that the signature can be validated agains the public key from the jwks endpoint with a with a matching kid in the token and in the jwks endpoint. Enabling or disabling PKCE didn’t make any difference in my case.

Don’t know what to try next, I guess opening a support ticket is the next step.

Hey @Rodrigo_Aguilera :waving_hand:

Thanks for sharing your setup—sorry to hear you’re running into the same issue here. The pattern we’re seeing (auth flow succeeds to token endpoint, but Shopify 401s without calling userInfo) does point to potential id_token validation failures on our end.. I really appreciate you already validating the claims, JWT signature, JWKS, and tried PKCE toggles—that rules out a lot.

To troubleshoot further, could you decode your id_token (e.g., via jwt.io, masking sensitive bits) and share those key claims like:

  • aud (should match Shopify’s client_id for your OIDC app),
  • iss, sub (unique per user), exp, iat, and any nonce values?

Also, it might help to confirm if your jwks_uri is publicly accessible. Since it works in the openidconnect.net playground, maybe test a manual token exchange with cURL against your Drupal endpoint to mimic Shopify’s request (or through Postman if you prefer a GUI).

If that doesn’t pinpoint it, just ping me here and I can get in touch with our product team to investigate this further for you and the other folks in the thread.

Thanks @Alan_G

Here is a fresh id_token captured at the identity provider and decoded
Header:

{
  "typ": "JWT",
  "alg": "RS256",
  "kid": "9e4ef48076d2abb65c484d1162f"
}

Payload:

{
  "aud": "BWRcjnmUF0OwJsAUN39a71CGmDgaUEa_xmhHPl3gz8I",
  "iss": "https://my-provider.com",
  "iat": 1752567178,
  "exp": 1752567478,
  "sub": "1",
  "name": "admin",
  "preferred_username": "admin",
  "email": "admin@example.com",
  "email_verified": true,
  "profile": "https://my-provider.com/user/1",
  "locale": "en",
  "zoneinfo": "Europe/Brussels",
  "updated_at": 1746459108,
  "groups": []
}

I’m sure the jwks_uri is public but I just checked the access logs and the url is never requested during the process. I even deleted the client on the shopify side and created it again with a new client ID and secret in the hope that will “refresh” some cache but the jwks_uri is not requested. I did change the kid yesterday so that could explain something.

Here is the output of https://my-provider.com/.well-known/openid-configuration
That is the full URL I input in the field Well-known or discovery endpoint URL in Shopify when configuring the identity provider.

{
  "issuer": "https://my-provider.com",
  "authorization_endpoint": "https://my-provider.com/oauth/authorize",
  "token_endpoint": "https://my-provider.com/oauth/token",
  "userinfo_endpoint": "https://my-provider.com/oauth/userinfo",
  "jwks_uri": "https://my-provider.com/oauth/jwks",
  "response_types_supported": [
    "code",
    "id_token",
    "token id_token"
  ],
  "subject_types_supported": [
    "pairwise",
    "public"
  ],
  "id_token_signing_alg_values_supported": [
    "RS256"
  ],
  "scopes_supported": [
    "openid",
    "profile",
    "email"
  ],
  "claims_supported": [
    "sub",
    "name",
    "preferred_username",
    "email",
    "email_verified",
    "locale",
    "profile",
    "updated_at",
    "zoneinfo",
    "groups"
  ]
}

I’m not an Oauth expert but could there be a problem with the access_token instead of the id_token like it reads in the error message from shopify?

Yesterday I connected another Drupal site to this Drupal provider successfully so I guess there is some small implementation detail in shopify that is different.

about the token:
iss: matches with shopify and the consumer configured in the provider
sub: I am only using one user
exp, iat: GMT timestamps

I opened the support ticket on Sunday and I didn’t receive an answer yet.

Hey again @Rodrigo_Aguilera

Thanks very much for sharing the above info there. I’ve taken a closer look, and everything seems solid on the claims side (iss seems to matche, sub is present, exp/iat look good, and the scopes align).

I believe that the “aud” claim (“BWRcjnmUF0OwJsAUN39a71CGmDgaUEa_xmhHPl3gz8I”) should exactly match the client_id in your Shopify OIDC app settings, could you double-check that and confirm here (masking if needed)?

Mismatches are a common reason for these kinds of failures, so I just wanted to confirm that to narrow down the issue.

It’s interesting that the jwks_uri isn’t being hit. I’m wondering if that might indicate that validation is failing earlier (e.g., before key fetching). Since you’ve validated the signature externally and it works in playgrounds, could you try try a manual simulation if you 'haven’t already?

Using cURL or Postman to exchange the code for tokens, ensuring the request mirrors Shopify’s (POST to your token_endpoint with grant_type=authorization_code, client_id, client_secret, code, and redirect_uri) could help us see if it’s an issue with the Shopify end of things).

If that doesn’t pinpoint it, could you share your Shopify client_id (for aud comparison) and any X-Request-ID from the 401 response (or just confirm if you’re setting up the OIDC in the admin? I’ll loop in with our product team to investigate potential OIDC validation quirks—feel free to DM me your shop ID if you’d like me to check logs internally too (I can set up the DM on my end here).

Hope to speak with you soon!

Hello @Alan_G

Thank you for the assistance.
Indeed the aud matches the client_id I configured on shopify and the consumer on my end. I changed it now to 04yYM6zwsN9zdmkyad1zqSNDdZJ9RFkPOrCOZN2iUS0.
I don’t think there is a problem sharing this here.

I’m not sure what I should look for in a manual simulation with curl or postman when I already tested two successful clients connecting.

The data I get on the 401 HTML

Request ID: 9ad81d1e-d7e1-40df-9de9-ac4d66a378b8-1752601047

state
01K07JJJQHSYY69DTK5E12EFFC

Do you have to open your DMs so I can send the shop info?

Hi @Rodrigo_Aguilera, I’ll set up the DM on my end here (currently for Shopify staff to open DMs with users on the forum we have to initiate them), but I’ll set that up right away here so we can look into this further that way. Speak with you there in just a second :slight_smile: