Authentication is scoped around the explicit trust boundaries, user roles, and compliance requirements of your application rather than generic boilerplate. The Technology department evaluates identity providers, session models, and role-based access controls during initial technical discovery to produce a fixed architecture and timeline.
Information required during discovery To determine the scope of an authentication system, the Technology department requires functional parameters before drafting a specification or bespoke quote. You must provide: - User types and hierarchy: A definitive breakdown of every actor interacting with the platform (for instance, public consumers, paying members, internal administrators, or third-party auditors). - Identity provider preferences: Confirmation of whether the platform relies on standard email and password credentials, passwordless magic links, social OAuth (such as Google, Apple, or GitHub), or enterprise Single Sign-On (SSO via SAML or OIDC). - Session and security policies: Rules regarding concurrent sessions, session lifetime, inactivity timeouts, multi-factor authentication (MFA) enforcement, and account lockout thresholds. - Regulatory and data residency demands: Geographic or industry compliance mandates (such as UK GDPR) that dictate where credential data, audit logs, and tokens may reside.
If these details are incomplete, bespoke scoping will pause until clarifications are logged via Ask Xylo.
Scoping tiers and technical implementation Authentication rarely exists in isolation; it dictates how your database schemas, API gateways, and client applications interact. We classify authentication builds into three distinct tiers:
1. Basic direct authentication: Single-role or simple two-role systems using secure password hashing (Argon2id or bcrypt) or magic links. Scoped for low-complexity web apps where external directory synchronisation is not required. 2. Role-Based Access Control (RBAC) and social integrations: Multi-role models where permissions govern access to discrete API routes and database tables. This tier includes OAuth 2.0 social logins, automated password reset flows, MFA via TOTP, and transactional security emails. 3. Enterprise federation and multi-tenancy: Complex architectures requiring SAML 2.0 or OIDC integration with identity providers such as Okta, Azure AD, or Google Workspace. This tier covers tenant isolation, automated SCIM provisioning, granular audit trails, and strict session revocation protocols across microservices.
Package builds include pre-defined authentication layers as stated on the packages page. Any requirement that diverges from those packaged boundaries is scoped as a bespoke component.