modify SessionToken to be compatible with Checkout UI Extension

[jeroendelau]

Checkout UI Extensions have session tokens, but they vary slightly from the token provided by Shopify Apps.

App Session Tokens
Checkout Extension Session Tokens

Key differences:

• iss, sid are not part of the token
• sub, optional
• dest: has no protocol prefix

By merging this PR people should be able to use session tokens obtained through useSessionToken, to interact with the back-end without modification.

[Kyon147]

@jeroendelau are you able to add a wiki page on how this would be use for the checkout extension vs the main laravel application?

[jeroendelau]

absolutely, I will try to get something in there before the end of the week.

[Kyon147]

@jeroendelau great work on this.
Just checking on this, do you need anything from me to get this passed with the check "linting" and then we can get it merged in

[jeroendelau]

No, sorry, simply had no time. Will fix

[jeroendelau]

I think I fixed all linter issues, but I'm having trouble reproducing the same error locally.
Added a wiki page here: https://github.com/Kyon147/laravel-shopify/wiki/Working-with-App-Extensions

[jeroendelau]

Added in separate PR #346

The reason I couldn't get the linter to fail was because the local version does not match the version of github actions.

github action 3.0.0
composer ^3.0 (which results in 3.59.3).

After setting composer to 3.0.0 the errors matched.

Suggest adjusting the lint action to use the composer version so mismatch can't happen.

name: PHP Lint

on: [ push, pull_request ]

jobs:
  lint:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout code
        uses: actions/checkout@v2

      - name: Setup PHP
        uses: shivammathur/setup-php@v2
        with:
          php-version: '8.2'
          coverage: none

      - name: Get Composer cache directory
        id: cache-composer
        run: echo "dir=$(composer config cache-files-dir)" >> $GITHUB_OUTPUT

      - name: Restore Composer cache
        uses: actions/cache@v3
        with:
          path: ${{ steps.cache-composer.outputs.dir }}
          key: ${{ runner.os }}-${{ github.ref_name }}-composer-${{ hashFiles('**/composer.lock') }}

      - name: Install Composer dependencies
        run: |
          composer install --no-interaction --prefer-dist

      - name: Check for code style violation with PHP-CS-Fixer
        run: vendor/bin/php-cs-fixer fix --diff

[Kyon147]

Looks great

[blazerunner44]

@jeroendelau Thanks for this PR! I've been working on a Customer Account UI extension. I've noticed this code improperly classifies the session token from the Customer Account UI extension as an app session token because the iss is included in the body. I don't have a Checkout UI extension to test with right away, but wanted to get your thoughts.

https://shopify.dev/docs/api/customer-account-ui-extensions/latest

[jeroendelau]

@blazerunner44 happy to hear someone is using it! I haven't worked with it for a while, so I didn't encounter this myself. But let's see if we can't resolve this.

So the original issue was that theAssert::thatAll([ .... ]) on line 182 failed. Since the checkout token did not include three of those fields consistently.

However, I didn't simply want to remove the check, so I tried to create a strict a scenario as I could to only skip checking it if specific fields were missing, and all missing.

Now that Shopify is sometimes adding these fields, it starts to become brittle.

So, from my perspective, We have two options:

1. remove the iss from determineTokenSource`

• Still attempt to communicate where the token might have come from
• If later Shopify decides to also issue ['sub'], it fails again
• Most backward compatible

2. Remove the requirement for iss, sid and sub to be not_null

• This will weaken checks for all tokens
• makes it future proof

add. with option 2, the need to determine tokenSource goes out the window. It could be removed, but I can't be sure that nobody is relying on it. Maybe we can find a different method?

[blazerunner44]

@jeroendelau Appreciate you taking the time with a thoughtful response. This is my first dive into Shopify and am very much figuring things out as I go.

Shopify didn't issue the iss field back when this PR was being worked on, but now it is included. Is it safe to say this code doesn't work across the board right now, or could there be cases where Shopify still doesn't issue the iss field (older API versions, Checkout UI vs Account UI extensions, etc)?

I do like the method to determine the tokenSource. Seems useful for people who might want to determine how a request is received.

A quick dive into the Shopify documentation about the sid field on the token indicates:
sid: A unique session ID per user and app.
Shopify docs

To me it makes sense that a sid wouldn't be issued for a checkout/account UI extension as there's no authenticated Shopify user using the app. Unless they change the definition in the future, it seems safe to remove the check for iss from determineTokenSource and rely soely on the sid field, your option #1 above.

[jeroendelau]

Makes sense, is this raised in an issue anywhere? Would you be ok to create a PR for this?

…

On Fri, 26 Sep 2025 at 18:22, Jaden Taylor ***@***.***> wrote: *blazerunner44* left a comment (Kyon147/laravel-shopify#329) <#329 (comment)> @jeroendelau <https://github.com/jeroendelau> Appreciate you taking the time with a thoughtful response. This is my first dive into Shopify and am very much figuring things out as I go. Shopify didn't issue the iss field back when this PR was being worked on, but now it is included. Is it safe to say this code doesn't work across the board right now, or could there be cases where Shopify still doesn't issue the iss field (older API versions, Checkout UI vs Account UI extensions, etc)? I do like the method to determine the tokenSource. Seems useful for people who might want to determine how a request is received. A quick dive into the Shopify documentation about the sid field on the token indicates: sid: A unique session ID per user and app. Shopify docs <https://shopify.dev/docs/apps/build/authentication-authorization/session-tokens> To me it makes sense that a sid wouldn't be issued for a checkout/account UI extension as there's no authenticated Shopify user using the app. Unless they change the definition in the future, it seems safe to remove the check for iss from determineTokenSource and rely soely on the sid field, your option #1 <#1> above. — Reply to this email directly, view it on GitHub <#329 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABIKX4SAJ4AF2BT5AWTWJNT3UVR4HAVCNFSM6AAAAACHQQPWZ6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTGMZZGQ2TSMBVGY> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[Kyon147]

I've been following your conversation, let me know when you want a review on this PR and thanks for your help 🙏

[blazerunner44]

@jeroendelau @Kyon147 Quick PR to remove the iss field check #452