ZuploZuplo
LoginStart for Free
  • Documentation
  • API Reference
Introduction
Getting Started
    Develop on the web portal
      1 - Setup Your Gateway2 - Rate Limiting3 - API Key Auth4 - Deploy5 - Dynamic Rate LimitingDynamic MCP Server - Quickstart
    Develop locally with the CLI
      1 - Setup Your Gateway2 - Rate Limiting3 - API Key Auth4 - Deploy5 - Dynamic Rate LimitingDynamic MCP Server - Quickstart
Concepts
Development
Policies
    Policy Catalog
    Authentication
    Authorization
    MCP Authorization
    Security & Validation
    Metrics, Billing & Quotas
    Testing
    Request Modification
    Response Modification
    Upstream Authentication
      OAuth AuthenticationSet Upstream API KeyUpstream Azure AD Service AuthUpstream GCP Service AuthUpstream GCP Federated AuthUpstream GCP Self-Signed JWTUpstream Firebase Admin AuthUpstream Firebase User AuthUpstream Zuplo JWT
    Archival
    GraphQL
    Other
    Guides
Handlers
API Keys
Rate Limiting
MCP Server
MCP Gateway
AI Gateway
Developer Portal
Monetization
Deploying & Source Control
Analytics
Observability
Networking & Infrastructure
Account Management
Programming API
Build with AI
Zuplo CLI
Migration Guides
Platform LimitsSecuritySupportTrust & ComplianceChangelog
powered by Zudoku
Upstream Authentication

OAuth Authentication

Zuplo comes with build-in and extensible OAuth policies out of the box. These policies allow you to easily authenticate requests using popular services like Auth0, AWS Cognito, and more.

Some of the built-in policies are listed below.

  • OpenId JWT Authentication Policy
  • Auth0 JWT Authentication Policy
  • Okta JWT Authentication Policy
  • AWS Cognito JWT Authentication Policy

Request User

The OAuth policies will validate and decode the incoming JWT and add the data from the JWT. If the user is successfully authenticated the claims of their JWT access_token will be available on the request.user object.

The user's identifier (also known as the sub or subject) is available on the request.user.sub property. Other claims can be found on the request.user.data object as demonstrated below.

Code
async function (request: ZuploRequest, context: ZuploContext) { // Log the user's sub context.log.debug(`User ${request.user.sub} is authenticated`) // Check a custom claim if (request.user.data["orgId"] === "1234") { // do something } }

Authorization Header

The built-in policies will validate the incoming JWT on the Authorization header. By default, the Authorization header will be left on the request and forwarded on to your backend.

It isn't recommended to validate the Access Token on both the gateway and the backend. However, by forwarding the header to the backend you can transition your API from doing authentication on your backend to authorizing at the Gateway. See this blog post for more details.

If you would like to remove the authorization header after you use one of the authorization policies, simply add the Remove Request Headers policy after the authorization policy and set it to remove the Authorization header.

Edit this page
Last modified on August 8, 2025
HTTP DeprecationSet Upstream API Key
On this page
  • Request User
  • Authorization Header
TypeScript