Authentication Developer Guide
Overview
1. User authenticates with FusionAuth → receives JWT
2. Application validates JWT via JWKS
3. Application resolves FusionAuth identity to internal user
4. Application stores tokens in httpOnly cookies
5. FusionAuth JWT passed directly to Neon for RLS
6. Neon uses auth_user() and is_authenticated() for access controlSetup
Environment Variables
# FusionAuth Configuration
FUSIONAUTH_URL=https://auth.refresh.tech
FUSIONAUTH_APP_ID=<application-id>
FUSIONAUTH_CLIENT_SECRET=<client-secret>
FUSIONAUTH_TENANT_ID=<fusionauth-tenant-id>
# Neon validates FusionAuth JWT directly via JWKS - no custom JWT keys needed
# PRIVATE_JWK_JSON and PUBLIC_JWK_JSON are no longer requiredFusionAuth SDK Setup
JWT Validation
Validating FusionAuth JWTs
Extracting Token from Request
Identity Resolution
Resolving FusionAuth ID to Internal User
Getting Work User ID for Tenant
Permission Checking
How Permissions Are Resolved
Permission Format
Resolving Permissions
Checking Specific Permission
Middleware Implementation
Auth Middleware
Type Definitions
UserSession Type
Usage in Routes
Protected API Route
Page Load Function
Personal Route (No Tenant Required)
Database Client with FusionAuth JWT
OAuth Callback Implementation
Token Refresh
Troubleshooting
JWT Validation Failing
Identity Not Linking
Permission Denied
Neon RLS Issues
Related Documentation
Last updated