[Shopify] Migrate Shopify Connector to Expiring Offline Access Tokens

[onbuyuka]

Background

As of December 2025, Shopify supports expiring offline access tokens with refresh-token rotation. Public apps created before 2026-04-01 must migrate to expiring tokens by 2027-01-01; after that date, REST/GraphQL Admin API requests made with non-expiring tokens are rejected. The Shopify Connector currently uses non-expiring offline tokens and must be migrated.

Token characteristics (Shopify):

• Access token lifetime: 1 hour (expires_in: 3600)
• Refresh token lifetime: 90 days (refresh_token_expires_in: 7776000)
• Migration is a one-time, irreversible token exchange per shop (the original non-expiring token is revoked on success)
• Only one refreshable expiring token per app + store

Refs: About offline access tokens - Migrating from non-expiring to expiring tokens

Approach

Token validity is centralized in a single orchestrator, EnsureValidAccessToken(Store), invoked from Shpfy Communication Mgt.GetAccessToken - so every API call (interactive and background) transparently migrates a legacy token or refreshes an expiring one before use. A scheduled backstop job additionally keeps idle shops access/refresh tokens alive and completes migrations for shops that never make an on-demand call.

Changes

Token storage - Shpfy Registered Store New (table 30138)

• New fields Token Expires At / Refresh Token Expires At; refresh token kept in IsolatedStorage.

Acquisition, refresh & migration - Shpfy Authentication Mgt. (codeunit 30199)

• New installs request expiring tokens (expiring=1).
• EnsureValidAccessToken orchestrates migrate-if-legacy / refresh-if-near-expiry, serialized per shop.
• RefreshAccessToken (grant_type=refresh_token) with transient retry and a terminal reconnect error.
• MigrateToExpiringToken (one-time token exchange, best-effort - keeps the working token on failure).
• ForceTokenRefresh, IsRefreshTokenExpired, and a Shop Card reconnect notification.

Consumption - Shpfy Communication Mgt.

• GetAccessToken invokes the orchestrator; reactive 401 -> refresh -> retry in ExecuteWebRequest.

Scheduled backstop - Shpfy Token Refresh (30431) + Shpfy Token Refresh Shop (30432)

• Dispatcher (TableNo = Job Queue Entry) iterates enabled shops and runs the per-shop worker (TableNo = Shpfy Shop) via Codeunit.Run for isolation; recurring Job Queue entry registered via installer + upgrade.

UX - Shpfy Shop Card

• Reconnect notification when the refresh token has expired.

Docs & tests

• Shpfy Token Refresh Test unit tests; living docs refreshed (business-logic, data-model, patterns, CLAUDE.md).

Telemetry

Emitted for migration success/failure, refresh success/transient/terminal and backstop per-shop failures, under event IDs 0000UIV-0000UJ1.

Test plan

• Shopify App project compiles clean.
• Shpfy Token Refresh Test unit tests for the expiry decisions.
• Install / refresh / migration / backstop / notification scenarios validated locally.

Fixes AB#637954

[github-actions]

Copilot PR Review

Iteration 11 · Outcome: completed

Knowledge source: https://github.com/microsoft/BCQuality@186d8a131465475c79244d994acb872cd5c0d4bf

Findings by domain

Findings split into Knowledge-backed (cite a BCQuality article) and Agent (the agent's own judgement, no matching BCQuality rule).

Domain	Findings	Knowledge-backed	Agent	Inline	Fallback
Error Handling	1	1	0	1	0
Performance	1	1	0	0	0

Totals: 2 knowledge-backed · 0 agent findings.

Orchestrator pre-filter (2 file(s) excluded)

• layer-disabled (knowledge) : 2 file(s)

_{Findings produced by the AL review agent v1.7.3. Reply 👎 on any inline comment to flag false positives.}

[github-actions]

$\textbf{🟠\ High\ Severity\ —\ Security} \quad \color{gray}{\texttt{\small Iteration\ 2}}$

SaveTokenResponse (new in this PR) stores the Shopify offline access token via RegisteredStoreNew.SetAccessToken(), which persists it with IsolatedStorage.Set (unencrypted at rest), while the refresh token introduced by this same PR is correctly stored via SetRefreshToken() using IsolatedStorage.SetEncrypted.

Both are OAuth credentials for the same store and belong in the same encrypted class. This inconsistency becomes load-bearing now: every store going forward will have an encrypted refresh token sitting next to an unencrypted, equally sensitive access token in the same record. Change SetAccessToken (Shpfy Registered Store New table) to use SetEncrypted for parity with the refresh token.

Knowledge:

• microsoft/knowledge/security/isolatedstorage-setencrypted-for-sensitive-values.md

Line mapping was unavailable, so this was posted as an issue comment.

_{👍 useful · ❤️ especially valuable · 👎 wrong - reply with why}

fixed

[github-actions]

$\textbf{🟠\ High\ Severity\ —\ Performance}$

ReconnectFromError scans every enabled shop with FindSet() and then tests Shop.GetStoreName() inside the loop. That store predicate can be pushed into the database with a filter on the shop URL instead of reading all enabled shops in AL before reconnecting the one matching store.

Knowledge:

• microsoft/knowledge/performance/apply-filters-before-iterating.md

_{👍 useful · ❤️ especially valuable · 👎 wrong - reply with why · AL review agent v1.12.4}

[github-actions]

$\textbf{🟡\ Medium\ Severity\ —\ Testing}$

RefreshTokenRoundTrips never checks that the token returned by GetRefreshToken is the same token written in SetupStore; it only asserts that some non-empty secret is returned. A broken implementation that returns the wrong token would still pass. Capture the generated refresh token and assert the exact round-tripped value.

_{👍 useful · ❤️ especially valuable · 👎 wrong - reply with why · AL review agent v1.12.4}