Authentication

​

Overview

​

Technology Stack

​

Authentication Flow

​

Password-Based Authentication

1. User registers with email and password
2. Password is hashed with bcrypt and stored
3. On login, credentials are verified
4. JWT access token + refresh token are returned
5. Access token is sent with each API request

​

OAuth Flow

1. Client initiates OAuth with PKCE
2. User is redirected to the provider (Google, GitHub, etc.)
3. Provider redirects back with authorization code
4. Yboard exchanges code for provider tokens
5. User account is created or linked
6. JWT tokens are returned to the client

​

JWT Token Structure

​

Token Payload

{
  "sub": "user-uuid",
  "email": "user@example.com",
  "role": "authenticated",
  "app_id": "project-uuid",
  "iat": 1700000000,
  "exp": 1700003600
}

​

Token Claims

​

API Endpoints

​

Authentication Endpoints

​

OAuth Endpoints

​

Admin Endpoints

​

OAuth Provider Configuration

• Google — OAuth 2.0
• GitHub — OAuth
• Custom providers — Any OAuth 2.0 / OpenID Connect compatible provider

​

Custom OAuth Providers

{
  "provider_name": "my-provider",
  "client_id": "your-client-id",
  "client_secret": "your-client-secret",
  "authorization_url": "https://provider.com/authorize",
  "token_url": "https://provider.com/token",
  "userinfo_url": "https://provider.com/userinfo",
  "scopes": ["openid", "profile", "email"]
}

​

Security Features

• bcrypt password hashing with configurable rounds
• JWT RS256 signing with per-project key pairs
• Refresh token rotation — old tokens are invalidated on refresh
• Rate limiting on auth endpoints
• Email verification with configurable OTP or link
• Password reset flow with secure tokens

​

Security Best Practices

1. Always use HTTPS in production
2. Store tokens securely — use httpOnly cookies or secure storage
3. Set short access token expiry — 1 hour recommended
4. Enable email verification for production apps
5. Use RLS policies to control data access per user