Why OAuth exists

Before OAuth, systems solved integration crudely: service A asked the user for their service B login and password, stored them and used them for access. That is unsafe for several reasons.

  • The password is held on someone else’s server.
  • Access is all or nothing — rights cannot be narrowed.
  • Revoking access means changing the password, which breaks every other service at once.

OAuth 2.0 solves this through delegation: service A receives a limited access token for specific resources in service B, without ever knowing the user’s password.

The main OAuth 2.0 flows

Authorization Code — the safest flow for web applications with a user in the loop:

1. Client -> authorisation server: request a code (+ state, redirect_uri)
2. Authorisation server -> user: the consent screen
3. User -> authorisation server: grants consent
4. Authorisation server -> client: authorization code
5. Client -> authorisation server: code -> access token + refresh token
6. Client -> API: Bearer access_token

Client Credentials — machine-to-machine, with no user involved. The personalization platform authenticates to the CRM with a client_id and client_secret and receives a token. No person takes part in the exchange.

POST /token
  grant_type=client_credentials
  &client_id=gf_platform
  &client_secret=*****
  &scope=catalog:read orders:read

-> { access_token: "eyJ...", expires_in: 3600 }

OAuth in e-commerce integrations

The typical scenarios where OAuth appears when connecting a personalization platform:

Integration Flow Purpose
Connecting a CMS (Shopify, WooCommerce) Authorization Code Access to the catalogue and orders on the store’s behalf
The personalization platform API Client Credentials The CMS server fetches recommendations
Connecting a CRM Client Credentials Exporting audience segments
Third-party analytics Authorization Code Reading data from GA4 or another system

Tip: request the minimum scopes you need. If the personalization platform only reads the catalogue, do not request write access to orders. That limits the damage if a token is compromised.

Common implementation mistakes

  • Not verifying the state parameter in the Authorization Code flow, which opens a CSRF hole.
  • Keeping a refresh token in LocalStorage, which is exposed to cross-site scripting; use an HttpOnly cookie.
  • Not refreshing the access token on expiry and failing silently with a 401 — the user sees an error instead of a re-authorisation.
  • Tokens that never expire — an access token with an unlimited TTL removes the main advantage of OAuth.