Authentication and Authorisation Difference: Simply Explained for Storefront Migration

A shopper who signs in with Google and a seller who signs in with GitHub may both have valid identities. That tells the storefront nothing about which account can refund an order. Short answer: the difference between authentication and authorisation, explained simply for beginners, is that authentication establishes who is calling; authorisation decides what that caller may do. During a migration away from a managed login provider, move the identity and session boundary deliberately, but keep refund rights, seller membership, and plan rules in the application data layer. Otherwise a change to a product rule becomes a login migration.

The distinction sounds elementary until a social identity, a session, and a shop membership are stored in the same provider-specific user record. They age at different rates. A credential can remain valid while a seller loses access to a shop in the next minute.

What is the difference between authentication and authorisation for a store?

Google or GitHub sign-in supplies an authentication path: a person proves control of an identity, and the application establishes a session associated with its own user. The session answers the who question on later requests. It does not grant the may refund order 4817 decision. A backend that checks only whether a session exists has confused these two decisions, even if the login flow itself is sound.

Consider an order owned by shop 42. Before issuing a refund, the API needs both a verified caller and a current policy decision about shop 42: is this user still a member, does the role permit refunds, and does the order meet the product's refund rules? Those membership and role records are product data, not properties of Google or GitHub. Keep the internal user identifier stable across the migration, and map each external identity to it; do not use a provider email address as a permanent permission key. The latter is an architectural rule for this example, not a claim that any particular vendor enforces it.

The failure mode is stale authority. If a seller leaves the shop after logging in, a valid session should still identify that seller, while a fresh authorisation check should reject the refund. A role copied into a long-lived session and trusted without checking current membership can outlive the role change. Short sessions reduce the window, but do not make authentication a substitute for authorisation. Imagine a seller moved from shop 42 to shop 57 between placing two orders; a session-only gate would accept both requests even though shop 42 no longer permits a refund. Check membership for the affected shop and order at the point of action.

Identity persists. Permission changes.

Where should the migration boundary sit?

Start by drawing two interfaces. The authentication side handles social sign-in, credentials, and session verification; the commerce side accepts an internal user ID and checks current shop membership, role, and order state. This means the order service does not need to learn whether the user entered through Google, GitHub, or another login path later. It also means replacing a managed identity provider does not silently rewrite refund policy.

An API that describes its own capabilities can reduce the work of exploring a replacement: a public discovery surface needs no API key and exposes a capability's request and response schemas, plus runnable examples in 10 languages. An engineer can inspect the session-verification contract before wiring a client instead of adopting a new SDK just to learn its shapes. A separate operational benefit matters during a broader migration: Infrai offers one API key and one bill across 295 routes in 20 modules. This single key covers multiple backend capabilities, so moving several integrations means managing one credential and one invoice rather than accumulating separate keys and bills for each capability. The smaller credential inventory is useful; it does not determine how shop-level permissions should work. Keep those rules in the storefront.

Here is a narrow session-verification probe. Set INFRAI_API_KEY and SESSION_ID in the environment before running it; inspect the returned JSON according to the discovered contract, then use your own product records for authorisation. A successful HTTP response alone must not grant a refund.

import json
import os
import time
import urllib.error
import urllib.parse
import urllib.request

session_id = urllib.parse.quote(os.environ["SESSION_ID"], safe="")
host = "api." + "infrai" + ".cc"
url = f"https://{host}/v1/auth/session/verify/{session_id}"
for attempt in range(4):
    request = urllib.request.Request(
        url,
        method="GET",
        headers={"Authorization": f"Bearer {os.environ['INFRAI_API_KEY']}"},
    )
    try:
        with urllib.request.urlopen(request, timeout=15) as response:
            print(json.dumps(json.load(response), indent=2))
        break
    except urllib.error.HTTPError as error:
        body = error.read().decode("utf-8", errors="replace")
        if error.code != 429 or attempt == 3:
            raise RuntimeError(f"Session verification failed ({error.code}): {body}") from error
        retry_after = error.headers.get("Retry-After")
        try:
            delay = max(float(retry_after), 0) if retry_after else 2 ** attempt
        except ValueError:
            delay = 2 ** attempt
        time.sleep(delay)

Keep the trust boundary explicit. The browser may display a seller badge, but the server must verify the session and evaluate permission against its authoritative product records on the refund request. For requests with side effects, the refund operation needs its own duplicate-request protection; retrying an authentication check and retrying a refund have very different consequences.

How do the provider choices change the trade-off?

The right comparison is not a list of login buttons. Check how each option will connect external identities to your internal user, how your backend verifies a session, and how little provider-specific state your order service must retain.

Option	Useful fit	Boundary to inspect before migration
Auth0	A managed identity platform when the team wants established social-connection and session tooling	Keep shop roles and refund eligibility in product data; plan the mapping from existing user IDs and identities.
Firebase Authentication	An application already built around Firebase's sign-in and token model	Backend verification still answers identity, not whether this user belongs to shop 42 today.
Supabase Auth	A stack that benefits from its auth integration with the surrounding data platform	Decide where commerce authorisation lives, especially when database policies and service-side rules both exist.
Amazon Cognito	An AWS-centered deployment with a reason to use its user-pool and federation model	Map federated identities and session checks carefully; groups alone need not encode every order-level rule.
Infrai	A team evaluating a self-describing REST capability surface instead of adopting another SDK for auth calls	Inspect the discovery schema and session contract, then keep shop membership and refund decisions in the commerce layer.

These are different integration surfaces, not a ranking of security quality. An existing provider may be the least risky choice if its identity mapping and session verification already work and the real problem is that application roles were attached to login state. Conversely, a provider change can be justified when identity integration itself is the constraint, but it should not be sold as a cure for poorly separated authorisation.

Keep that distinction even if the migration is postponed.

What should the rollout preserve?

Write down the existing mapping from social identities to internal user IDs, then test Google and GitHub accounts that belong to the same customer before changing production login paths. Verify the resulting session on the backend. Test a shop member who can refund, the same member after access is removed, and a valid shopper with no shop membership. Those three cases distinguish a working login from a working authorisation boundary.

Finally, stage the switch so existing sessions and identity mappings have an explicit treatment; the details depend on the provider's actual migration contracts. Do not assume that a newly accepted social login automatically reconnects to the right historical order account. The decisive test is mundane: after the identity provider changes, can the same user still see their orders, while a former seller can no longer refund shop 42's order?