Get Started
Introduction
.png)
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 Options | Description | APIs |
---|---|---|
Authenticate | Integrate 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 Management | Implement 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.
Type | Description |
---|---|
Registered User | Full account - Login with email/password - Password reset & E-Mail update possible - Persistent & unique profile till deletion |
Guest User | One-time checkout - No login - E-Mail can be reused - Auto-deleted after usage |
Identity Provider User | Full 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 Type | Validation Features | Additional Notes |
---|---|---|
Email | Format checks, min/max length, optional (nullable) | Layered validations possible |
Password | Format checks, min/max length, optional (nullable) | Layered validations possible |
First name , Last name | None | Support flexible validations |
Gender | None | 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.