Authentication & Authorization Standard

User authentication methodology, access controls, and API security measures

Authentication & Authorization

Field Value
Document ID STD-003
Classification Internal
Owner CTO (interim CISO)
Effective Date April 2026
Review Cycle Annual

This document details the authentication and authorization mechanisms implemented across the Wealthy platform to ensure secure access to systems and data.

Authentication by User Type

Users (Customers)

  • First Factor: OTP (One-Time Password) via SMS/Email
  • Second Factor: PIN-based authentication
  • Required for all login attempts and sensitive operations
  • There is an additional otp / pin for transactions like SIP, Mandate, etc as per use case
  • For mobile subsequent access is via Biometric(fingerprint, FaceID) if enabled by users else pin.

2FA Implementation Documentation

📁 2FA User Implementation Circulars

This folder contains detailed documentation on 2FA implementation for users including regulatory requirements, technical specifications, and implementation guidelines.

Security Features

  • Device Management: Trusted device registration and management
  • Account Recovery: Secure account recovery through details verifications.

Partners

Authentication Methods

  • Mobile App Authentication:

    • OTP (One-Time Password) verification
    • Biometric authentication (fingerprint, Face ID)
    • Device binding and trusted device management
  • API Access Authentication:

    • API key-based authentication for system integrations
    • Post login api token is generated which is used for accessing apis.
    • Rate limiting and throttling controls are added.

Security Features

  • Partner Verification: Authentication linked to verified partner agreements
  • Role-Based Access: Different access levels based on partnership type
  • Audit Logging: Comprehensive logging of all partner activities
  • IP Whitelisting: Restricted access from approved IP addresses only for specific service
  • GEO Blocking: Internal tools api are accessible only from few countries.

Partner Support

Authentication Methods

  • System-Generated Credentials:

    • Username/password generated by system administrators
    • No self-registration or password reset capabilities
    • Session timeout after 8 hours of inactivity
  • Customer Support Tools:

    • Role-based access to customer support systems
    • Read-only access to customer data

Internal Staff (Operations, Developers, Business)

Authentication Methods

  • Google Login Authentication:

    • Google Workspace SSO for all internal applications and tools
  • System and Development Access:

    • Google-authenticated access to all internal systems
    • Git repository access with wealthy email
    • Development and production server access through Google SSO
    • Server access also needs VPN to be enabled

Security Features

  • Pritunl VPN Security Layer: All internal tools accessed through Pritunl VPN for additional security
  • Pritunl VPN Authentication: Pritunl VPN login authenticated through Google OAuth
  • Device Management: Corporate-managed devices with security policies
  • VPN Access: Mandatory Pritunl VPN for all internal dev tools access(like airflow, kubernetes, grafana, etc)
  • Email Security: Google Workspace Security
  • Audit Trail: Logging of all internal staff activities

Role-Based Access Control (RBAC) System

RBAC Architecture

The Wealthy platform implements a comprehensive RBAC system that manages access control through groups and permissions across all services:

Core Components

  • Groups: Logical collections of users with similar access requirements
  • Permissions: Granular access rights to specific resources or operations
  • Tokens: All generated tokens are tagged with relevant groups and permissions
  • API Gateway: Centralized token verification and header injection
  • RBAC Service: Validates permissions and provides group access information

Actual RBAC Flow

API Call → Gateway Token Verification → Header Injection (user_id, permissions, groups) → Service Permission Check → Data Filtering → Response

The same RBAC system is used across all services in the platform.

API Authentication

Common API Authentication Flow

All APIs in the Wealthy platform follow a standardized authentication flow through multiple security layers:

Architecture Overview

Client Request → Cloudflare → Wealthy Gateway → Microservices

Security Layer Flow

  1. Cloudflare Protection:

    • DDoS protection and traffic filtering
    • Initial request validation and security checks
    • Bot detection and mitigation
    • AI scrapper protection
  2. Wealthy Gateway Processing:

    • Authentication Check: Token validation and user verification
    • Rate Limiting: Request throttling based on user/IP/endpoint
    • Geo Checks: Geographic access restrictions and blocking
    • Header Injection: User context and permissions attached to headers
  3. Microservice Processing:

    • Service receives request with injected security headers
    • Function-level permission validation
    • Data filtering based on user context
    • Business logic execution

Gateway Security Features

  • Authentication: Token validation
  • Rate Limiting: Rate limits based on user type and API endpoint
  • Geographic Restrictions: Country-level access controls for sensitive APIs
  • IP Whitelisting: IP restrictions for enhanced security
  • Real-time Monitoring: Anomaly detection and threat response
  • CORS Policy: Cross-origin request restrictions

Token Management

  • Tokens: Stateless/stateful authentication tokens as per auth
  • Token Revocation: Immediate token invalidation for security incidents
  • Multi-Device Support: Separate token management for different device types

API Security Controls

  • API Versioning: Version-specific access controls and deprecation management
  • Payload Validation: Request and response validation and sanitization
  • Error Handling: Secure error responses without information disclosure

Group Management

User Groups

  • Family User: Portfolio viewing only
  • Admin Users: Portfolio viewing, trading permissions

Partner Groups

  • Partner Admin: With full access
  • Employee: Full Access except revenue

Internal Staff Groups

  • Operations Group: Back office related permissions, Order updates, Feed uploads.
  • Tech & Product Group: Code repository, controlled, server access, CDN management
  • Finance Group: Access for revenue related features
  • Business Product: Access to manage product metadata.
  • Marketing Group : Campaign and template system access

Permission Framework

Granular Permission System

The platform uses specific, granular permissions rather than broad categories. Each permission is action-specific:

Example Granular Permissions

  • can_generate_report: Generate Specific Reports
  • can_update_bank_account: Permission to modify bank account details

Permission Assignment

  • Group-Based: Permissions assigned to groups, users inherit from group membership
  • Function-Specific: Each API endpoint/function checks for specific required permissions
  • Atomic Operations: Each permission covers a single, specific action or resource
  • Inheritance: Users can belong to multiple groups and inherit all associated permissions

RBAC Service Integration

Gateway-Based Permission Flow

  1. API Call Received: Client makes API call with authentication token
  2. Gateway Token Verification: API Gateway validates token authenticity
  3. User Context Extraction: Gateway extracts user_id, groups, and permissions from token
  4. Header Injection: Gateway attaches user info and permissions to request headers
  5. Service Permission Check: Downstream service reads headers and validates group access to specific function
  6. Data Filtering: Service filters data based on user_id from headers and permission checks
  7. Response Generation: Service returns appropriately filtered response

Service-Level Implementation

  • Header Reading: Each service reads injected headers (user_id, groups, permissions)
  • Function-Level Access: Services check if user’s groups have access to specific functions
  • Data Row-Level Security: Data filtering implemented using user_id and permission groups
  • Consistent RBAC: Same RBAC logic applied across all microservices
  • Performance Optimization: Headers eliminate need for repeated RBAC service calls

Group and Permission Management

Administrative Controls

  • Centralized Group Management: All user groups and memberships managed centrally
  • Permission Assignment: Granular assignment of permissions to groups
  • Dynamic Updates: Real-time updates to group memberships and permissions
  • Token Regeneration: Updated permissions reflected in new tokens upon re-authentication

Data Access Control

  • User-Based Filtering: Data filtered using user_id from injected headers
  • Group-Based Permissions: Function access determined by RBAC group membership
  • Row-Level Security: Individual data records filtered based on user permissions
  • Cross-Service Consistency: Same user context and permissions across all services

Compliance and Governance

  • Segregation of Duties: Critical operations require multiple permission sets
  • Least Privilege Principle: Users assigned minimum required permissions
  • Audit Trails: Complete logging of RBAC decisions and data access patterns
  • Performance Monitoring: Gateway and service-level RBAC performance tracking

Contact Information