feat: enhance login command with direct user login support

[victorvhs017]

Description 📣

PR Description

This PR adds support for non-interactive user authentication via command-line flags and environment variables, enabling automated login workflows for CI/CD pipelines and scripting scenarios.

📋 Changes

New Flags

• --email: Email address for user login
• --password: Password for user login

Environment Variables (reuses existing infrastructure)

• INFISICAL_EMAIL: Email for authentication
• INFISICAL_PASSWORD: Password for authentication
• INFISICAL_API_URL: Domain configuration (existing env var)

JWT Token Output

• Displays JWT token after successful user login (both interactive and direct)
• --plain flag support: outputs only the JWT token for scripting
• Consistent with other authentication methods (universal-auth, etc.)

Login Flow (Priority Order)

1. Direct Login: Both --email and --password (or env vars) set → non-interactive
2. Interactive Login: --interactive flag → CLI prompts
3. Browser Login: Default → opens browser

Validation & Error Handling

• Validates that both email AND password are provided together
• Returns clear error message listing missing flags if only one is provided
• Email format validation before API calls
• Password presence validation

Other Improvements

• Automatic domain selection: Uses preset domain (via --domain flag or INFISICAL_API_URL env) for direct login
• Browser login fallback to CLI on failure
• Code cleanup: Removed unused Argon2 imports and functions
• Improved UX messaging for browser login
• Better error messages and debug logging

---

Type ✨

• Bug fix
• New feature
• Improvement
• Breaking change
• Documentation

Tests 🛠️

Core Use Cases

Test Case	Command	Expected Result
Browser Login (Default)	./infisical login	Domain prompt → Browser opens → Success + JWT displayed
Interactive CLI	./infisical login --interactive	Prompts → Success + JWT displayed
Direct - US Cloud	./infisical login --email "user@example.com" --password "pass" --domain https://app.infisical.com	No prompts → Success + JWT displayed
Direct - EU Cloud	./infisical login --email "user@example.com" --password "pass" --domain https://eu.infisical.com	No prompts → Success + JWT displayed
Direct - Plain Output	./infisical login --email "user@example.com" --password "pass" --domain https://app.infisical.com --plain	Outputs only JWT token
Direct - Custom Domain	./infisical login --email "user@example.com" --password "pass" --domain https://infisical.company.com	Success + JWT displayed

JWT Token Output

# Normal login - displays formatted output with JWT
./infisical login --email "user@example.com" --password "pass" --domain https://app.infisical.com
# Output includes:
# User Token:
# eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...

# Plain output - only JWT (for scripting)
JWT_TOKEN=$(./infisical login --email "user@example.com" --password "pass" --domain https://app.infisical.com --plain)

Environment Variables

# Using env vars with existing INFISICAL_API_URL
export INFISICAL_EMAIL="user@example.com"
export INFISICAL_PASSWORD="pass"
export INFISICAL_API_URL="https://app.infisical.com/api"
./infisical login  # No prompts, outputs JWT

# Plain output with env vars
./infisical login --plain  # Only JWT token

Error Handling

# Missing password → Error
./infisical login --email "user@example.com"
# Error: missing flags for the user login method: [--password]

# Missing email → Error
./infisical login --password "pass"
# Error: missing flags for the user login method: [--email]

# Missing both email and domain → Falls back to interactive/browser login
./infisical login

# Invalid email format → Error
./infisical login --email "invalid" --password "pass" --domain https://app.infisical.com
# Error: please provide a valid email address

# Wrong credentials → Authentication error
./infisical login --email "user@example.com" --password "wrong" --domain https://app.infisical.com

CI/CD Simulation

#!/bin/bash
export INFISICAL_EMAIL="ci-user@example.com"
export INFISICAL_PASSWORD="SecurePass123!"
export INFISICAL_API_URL="https://app.infisical.com/api"

# Store JWT for reuse
JWT_TOKEN=$(./infisical login --plain)
echo "Logged in successfully"

# Use CLI for operations
./infisical secrets --projectId="PROJECT_ID" --env="dev"

Partial Env Var Usage

# Email from env, password from flag
export INFISICAL_EMAIL="user@example.com"
./infisical login --password "pass" --domain https://app.infisical.com

# Password from env, email from flag  
export INFISICAL_PASSWORD="pass"
./infisical login --email "user@example.com" --domain https://app.infisical.com

---

• I have read the contributing guide, agreed and acknowledged the code of conduct. 📝

[greptile-apps]

Greptile Overview

Summary

This PR adds support for direct user login via command-line flags (--email, --password, --hosting) and corresponding environment variables (INFISICAL_EMAIL, INFISICAL_PASSWORD, INFISICAL_HOSTING), enabling non-interactive authentication flows for CI/CD and automation scenarios.

Key Changes:

• Introduced three new flags and environment variables for direct user authentication
• Added domain configuration support for Infisical Cloud US, EU, and custom self-hosted instances
• Refactored login flow to handle three paths: browser login, interactive CLI login, and direct login
• Extracted validation functions (validateEmailInput, validatePasswordInput, validateURLInput) for better code reusability
• Added setDirectUserLoginDomain() to handle domain configuration for direct login flows
• Removed unused params struct and generateFromPassword() function

Code Quality Improvements:

• Better separation of concerns with extracted helper functions
• Improved error messages with more specific validation feedback
• Added debug logging for environment variable usage

Confidence Score: 3/5

• This PR is generally safe but has a logic issue that could cause confusing user experience
• The implementation is mostly solid with good refactoring and extracted validation functions. However, the isDirectUserLoginFlagsAndEnvsSet() function uses OR logic that allows partial flag sets (e.g., only --email without --password), which will cause delayed errors when GetCmdFlagOrEnv() tries to retrieve missing values. This creates a poor UX where users might think they're entering direct login mode but get cryptic errors later. The fix is straightforward - require all three parameters together.
• Pay close attention to packages/cmd/login.go - specifically the isDirectUserLoginFlagsAndEnvsSet() function around line 958

Important Files Changed

File Analysis

Filename	Score	Overview
packages/cmd/login.go	4/5	Adds direct user login via flags/env vars with domain configuration. Refactored code improves readability. Minor logic concern with partial flag/env checking.
packages/util/constants.go	5/5	Added three new environment variable constants for user authentication - straightforward addition with no issues.
packages/util/helper.go	5/5	Added debug logging to GetCmdFlagOrEnv - helpful for troubleshooting, no issues identified.

Sequence Diagram

sequenceDiagram
    participant User
    participant CLI as Login Command
    participant Flags as Flag Parser
    participant Domain as Domain Config
    participant Auth as Auth Flow
    participant API as Infisical API
    participant Storage as System Storage

    User->>CLI: Execute login command
    CLI->>Flags: Check for direct login flags
    Flags-->>CLI: Return flag status
    
    alt Domain Selection Required
        CLI->>Domain: Configure domain
        alt Preset Domain
            Domain->>Domain: Apply config
        else Custom Domain
            Domain->>Domain: Validate URL
            Domain->>Domain: Save to config
        end
    end
    
    alt Browser-based Login
        CLI->>Auth: Start browser flow
        Auth->>API: Browser authentication
        API-->>Auth: Return auth data
    else Direct Login
        CLI->>Flags: Get user inputs
        Flags->>Flags: Validate inputs
        Flags-->>CLI: Validated data
        CLI->>Auth: Execute CLI login
        Auth->>API: Send auth request
        alt V3 Success
            API-->>Auth: Return token
        else SRP Required
            API->>Auth: Legacy SRP flow
            API-->>Auth: Return auth info
        end
    end
    
    Auth-->>CLI: Authentication complete
    CLI->>Storage: Persist session
    CLI->>User: Success message

Loading

_{3 files reviewed, 1 comment}

_{Edit Code Review Agent Settings | Greptile}

[varonix0]

I'm not sure we actually want to always display this? For user auth I would opt to have this only returned with the --plain tag. I think the idea is that people are able to retrieve the token for things like CI steps, which I think they should be able to achieve by using the --plain tag.

It makes sense to display it for machine identity auth methods because they are expected to always be used as apart of CI steps - user auth is not intended to be used in CI steps usually

[victorvhs017]

Updated, and the token only shows with the --plain tag