docs
  1. Checkout Guide
  2. Authentication & Accounts
  3. Authentication API
  4. Get Started

Get Started

Introduction

SCAYLE's Authentication Service offers a robust and scalable solution for managing user authentication. It is built around the OAuth 2.0 and OpenID Connect (OIDC) protocols, providing a secure framework for handling authentication across various platforms.

Integration Options

The Authentication Service offers comprehensive flows for user login, registration, and guest access, supports seamless Single Sign-On with external Identity Providers, and provides robust Token Management to keep sessions secure and uninterrupted.

Integration OptionsDescriptionAPIs
AuthenticateIntegrate OAuth 2.0 flows to support login, registration, and password reset via SCAYLE’s Authentication APIs - optimized for headless storefronts.OAuth API
Single Sign-On Leverage authentication flows with external Identity Providers to enable secure and seamless SSO experiences using redirect-based integration.Bearer API
Token ManagementImplement OAuth 2.0 Bearer Token handling for secure session management — including access token validation, refresh token flows, and token revocation.IDP API

User Identities

The table below outlines the different customer identity types supported by the SCAYLE Authentication system, including their persistence, identifiers, and key capabilities. Through account linking, email-based accounts can be associated with newly created Identity Provider accounts; however, merging two existing accounts is currently not supported.

TypeDescription
Registered UserFull account - Login with email/password - Password reset & E-Mail update possible - Persistent & unique profile till deletion
Guest UserOne-time checkout - No login - E-Mail can be reused - Auto-deleted after usage
Identity Provider UserFull account - Login via SSO - No password reset & E-Mail update possible - Multiple identites across IDPs can be possible but only once per IDP

Configuration & Validation

SCAYLE’s Authentication Service enforces global API schema validations for both Components and Backend APIs.

Input Validation

Field TypeValidation FeaturesAdditional Notes
EmailFormat checks, min/max length, optional (nullable)Layered validations possible
PasswordFormat checks, min/max length, optional (nullable)Layered validations possible
First name, Last nameNoneSupport flexible validations
GenderNone

Additional genders like neutral

or not specified are possible


Dynamic Input Fields

Dynamic fields such as birthDate, address or phoneNumber are not supported directly during registration via the Authentication API, but other APIs such as the Customer Account or Admin APIs can be used to update the customer object after initial customer creation.

Token

SCAYLE issues access and refresh tokens on login, registration, or IDP authentication. Token lifetimes are configurable or aligned with IDP limits within SCAYLE’s bounds. Further Token Management includes validation, renewal, and revocation to keep sessions secure and seamless.

Refer to the Token Management Guide for more information on Token Management.

{% content-ref url="token-management/" %} token-management

Security

IP Throttling

SCAYLE provides throttling measures for authentication endpoints (auth/login and /token) to ensure fair usage and system stability.

To enable or adjust the rate limit, contact your SCAYLE Account Manager for further assistance.

By default, throttling is disabled, but when enabled, it limits the number of tokens issued per customer_ID within a defined time window. If this limit is exceeded, the API enforces a hard restriction, returning a 429 Too Many Requests status code without issuing a new token. There is no predefined hard limit; instead, it is configurable based on business requirements.


Validate Token Properly

Ensure that tokens are validated correctly by checking their signature, expiration time, and other claims. Use libraries like jsonwebtoken in Node.js to simplify this process.


Secure Token Storage

Contact your SCAYLE Account Manager for best-practices and further assistance.

Storing tokens in localStorage or sessionStorage exposes them to cross-site scripting (XSS) attacks. Tokens should be stored securely to prevent unauthorized access. Refresh Tokens should be never stored or exposed to the Frontend.