Authentication

Overview

Authentication pages are the entry points to your application. They determine whether a user can access your product and how smoothly they can begin using it. Byteion provides production-ready layouts for sign-in, sign-up, password recovery, OTP verification, social authentication, and enterprise SSO — all built from core components (Card, Input, Button, Checkbox, Divider, Alert, Form Field). These patterns work across SaaS dashboards, admin panels, Laravel starter kits, React apps, Vue apps, ecommerce back offices, ERP and POS systems, and internal tools.

When to use

• Sign-in pages for existing users
• Sign-up or registration pages for new accounts
• Password recovery flows — forgot password, reset password
• OTP or multi-factor verification screens
• Passwordless or magic-link authentication
• Social OAuth provider selection
• Enterprise SSO login with company domain

Authentication flows

The sign-in card layout is the base pattern from which all other auth flows are derived. Each flow uses the same centered card surface with flow-specific fields and actions.

Full UI example

Complete sign-in page implementation with validation-ready structure:

Component breakdown

This layout combines these Byteion components:

Validation and error states

Authentication forms should handle validation at two levels: field-level and form-level. Field-level errors appear below the specific control. Form-level errors appear as an Alert above the form.

Field-level validation

• Invalid email format — "Please enter a valid email address."
• Missing required field — "Password is required."
• Weak password — "Must be at least 8 characters with a number and a letter."
• Invalid OTP — "The code you entered is incorrect or expired."
• Password mismatch — "Passwords do not match."

Form-level validation

• Invalid credentials — "Invalid email or password. Please try again." Use a generic message; do not reveal whether the email exists.
• Account locked or disabled — "Your account has been temporarily locked. Please try again later or contact support."
• Rate-limited — "Too many attempts. Please try again in a few minutes."
• Session expired — "Your session has expired. Please sign in again."

Validation behavior

• Validate on blur for field-level format and requirement checks.
• Show credential errors only after form submission — never before.
• Do not reveal whether an email exists during password recovery. Show a neutral message: "If an account with this email exists, you will receive a reset link shortly."
• Show password reset and magic-link confirmation messages neutrally.
• Preserve user input after validation failure except for sensitive fields (password, OTP) when security policy requires it.
• Prevent duplicate submissions by disabling the submit button while loading.

Accessibility

• Every field must have a visible label. Placeholder text is not a label — it disappears on input and fails WCAG 3.3.2.
• Use aria-describedby to connect helper text and error messages to their form control. Screen readers announce the description when the field receives focus.
• Use aria-invalid="true" on fields with validation errors. This tells assistive technology the value is not valid.
• Use an error summary for form-level failures. After a failed submission, render an Alert with role="alert" at the top of the form and move focus to it using tabindex="-1".
• Move focus to the first invalid field after a failed submission so keyboard and screen-reader users can immediately correct the issue.
• OAuth buttons must include the provider name in accessible text. An icon-only button with aria-label="Sign in with Google" meets this requirement. A bare icon does not.
• OTP inputs must remain keyboard-friendly. Each digit slot should be reachable, and the group should support paste from SMS or authenticator apps.
• Do not rely on color alone for error or success states. Use text labels, icons, and aria-invalid in addition to text-danger.

Mobile and password-manager support

Authentication pages must work reliably with browser password managers and mobile keyboards. Use the correct input types and autocomplete attributes for every field:

Additional guidance

• Mask passwords by default. Add a show/hide password toggle (eye icon) when users need to verify what they typed — especially on sign-up and reset-password screens.
• Do not remove password manager support. Always set autocomplete correctly. Never use autocomplete="off" on password fields.
• Do not block paste in password or OTP fields. Users rely on paste from password managers and SMS apps.
• Keep name attributes predictable — password managers use name to identify fields across sessions.
• Use type="email" on email fields to trigger the email keyboard on mobile (with @ and . shortcuts).

Loading and disabled states

• Disable the submit button while submitting — use the disabled prop or attribute to prevent double submissions.
• Show Button loading state — when the Button component supports loading, show a Spinner inside the button while the request is in flight.
• Prevent duplicate requests — disable all form controls during submission, not just the submit button.
• Keep OAuth buttons disabled while a provider redirect is starting to prevent multiple redirect attempts.
• Show neutral success states after password recovery or magic-link requests — confirm the action without revealing user status.

Security and privacy notes

• Do not expose account existence in recovery flows. Use a generic message: "If an account with this email exists, you will receive instructions shortly."
• Do not log passwords or OTP values on the client side. Never send sensitive values to analytics or error-tracking services.
• Avoid putting tokens in visible examples. Use placeholder values like <token> or YOUR_API_KEY in documentation.
• Use HTTPS in production. Authentication pages must always be served over a secure connection.
• Backend must handle rate limiting, account lockout, email verification, session security, CSRF tokens, and MFA where required. The UI should not claim security guarantees that the backend does not enforce.
• Do not disable password managers — they improve security by generating and storing strong, unique passwords.
• Keep OTP codes transient. OTP inputs should clear after a failed attempt and never cache the value.

Auth layout patterns

Authentication screens follow a few common layout patterns. Choose the one that matches your brand and use case.

Best practices

Variations

Developer tips

Common mistakes

• Placeholder-only labels — placeholder disappears on input and fails WCAG. Always use visible labels.
• Revealing account existence during recovery — "No account found" or "Reset link sent" differently enables email enumeration.
• Blocking paste on password or OTP fields — users rely on paste from password managers and SMS apps.
• Showing errors before submission — credential errors should only appear after the form is submitted.
• Missing autocomplete attributes — without these, password managers cannot fill fields and mobile keyboards use incorrect layouts.
• Using autocomplete="off" on password fields — this disables password managers and harms security.
• Not disabling the submit button while loading — double submissions cause duplicate requests and confusing error states.
• Hiding sign-up or reset links — new users need clear paths to create accounts and recover access.

Production checklist

• Test form validation with keyboard only — Tab through all fields, verify error announcements, confirm focus moves to the first invalid field.
• Test screen reader announcements — labels, helper text, and error messages must all be announced when the field receives focus.
• Test dark mode and branded themes — all tokens (bg-card, text-foreground, text-muted-foreground, text-danger) must remain distinguishable.
• Test mobile viewports — ensure the card does not overflow and all fields are reachable.
• Test password-manager autofill on multiple browsers — Chrome, Safari, Firefox, Edge, and 1Password/Bitwarden.
• Test OTP paste from SMS and authenticator apps on iOS and Android.
• Test server-side validation errors mapped to the correct field.
• Verify all autocomplete attributes are correct per form context.
• Confirm no tokens, secrets, or API keys appear in any visible examples.
• Test loading and disabled states — submit button must be disabled while the request is in flight.

Premium examples

Advanced patterns available in Pro extend authentication into richer product contexts and multi-step flows.

• Multi-step onboarding auth flow — sign-up followed by workspace creation, team invitation, and preference setup, each in a separate Card step coordinated with Stepper.
• Enterprise SSO screen — company email input that detects the SSO provider and redirects to the identity provider. Includes a "Contact your IT admin" help link.
• OTP verification flow — email or phone input followed by a 6-digit OTP input with auto-submit, resend timer, and error handling for expired codes.
• Passwordless magic-link flow — single email field with "Send magic link" button and a confirmation screen with instructions to check the inbox.
• Branded split-screen auth template — full-page layout with brand illustration, testimonial quote, or product screenshot on one side and the auth form on the other.
• Auth form with validation summary — Alert at the top of the form listing all field errors after a failed submission, with links that move focus to each invalid field.
• Social auth provider grid — a 3x2 or 2x2 grid of provider buttons (Google, GitHub, Microsoft, Apple, GitLab, Bitbucket) with icons and accessible labels, separated from the email form by a divider.

Related components and pages

• Auth Sign In — pre-built sign-in page component
• Auth Sign Up — pre-built sign-up page component
• Auth Forgot Password — password recovery form component
• Auth Reset Password — password reset form component
• Auth OTP — one-time password entry component
• Input — form control used inside auth forms
• Button — action triggers with loading state
• Form Field — label, helper, and error wrapper for each field
• Checkbox — "Remember me" toggle
• Alert — form-level error summary
• Card — auth form surface container
• Spinner — loading indicator for submit buttons