Build secure software and web applications
Move from security requirements through safe implementation, browser boundaries, authorization tests, and vulnerability response.
Topic index
Application and Service Access
Learn how identity-aware access protects web applications, APIs, and non-HTTP services.
Topic index
Understand this domain
Pomerium coverage
Pomerium can proxy protected HTTP and WebSocket routes, tunnel supported TCP and UDP protocols, and provide native SSH access. It can send a signed identity assertion to an upstream HTTP application. Each route needs a reachable upstream and an explicit policy.
Limits
- One HTTP route does not cover a service protocol that uses a separate port or transport.
- TCP and UDP tunnels require a supported Pomerium client. Native SSH has separate server requirements.
- A protected route does not make an unsafe upstream application safe.
Primary sources
2 learning paths
Paths for this topic
Protect application and service access
Design browser, API, service, SSH, TCP, and UDP access without losing identity or creating a direct bypass.
21 related guides
Guides in this topic
Authorize HTTP tunnels and upgrades
Place authentication and authorization around WebSocket upgrade, HTTP CONNECT, CONNECT-UDP, and long-lived tunnels.
Choose layer 4 or layer 7 access control
Place transport and application enforcement where the required identity, destination, protocol, resource, and action are visible.
Choose the access enforcement layer
Place access enforcement across identity-aware proxies, API gateways, service meshes, load balancers, and network tunnels.
Choose where authorization decisions and enforcement run
Compare central and local authorization while preserving complete enforcement, current context, and safe failure behavior.
Compare zero trust deployment models
Compare device agent and gateway, enclave gateway, resource portal, and application sandbox deployment boundaries.
Constrain an access token to its sender
Compare bearer, DPoP, and mutual-TLS token use and test proof binding, freshness, audience, and replay defenses.
Design access control during failure
Define fail-closed, fail-open, degraded, cached, and break-glass states for every access dependency before an outage.
Design human and non-human identity lifecycles
Give people, services, workloads, devices, and agents distinct identity, delegation, credential, and revocation models.
Design identity-aware API access
Protect API inventory, clients, routes, versions, objects, actions, credentials, quotas, and evidence with explicit owners.
Design identity-aware TCP and UDP access
Map user identity and policy to non-HTTP connections while controlling clients, ports, names, lifetime, and protocol limits.
Design service-to-service access
Authenticate workloads, preserve human actor context, authorize target actions, and manage machine credentials through their lifecycle.
Distinguish proxy types before placing access control
Distinguish reverse, forward, transparent, and identity-aware proxies by client, destination, trust, and enforcement role.
Pass verified identity to an upstream application
Carry signed identity context across a proxy boundary and validate issuer, audience, signature, time, and delivery path upstream.
Protect private SSH and RDP administration
Design named administrative access with strong identity, narrow routes, native server controls, session limits, and evidence.
Protect upstream identity headers from spoofing
Remove untrusted identity fields, authenticate the proxy path, validate signed assertions, and close direct-origin bypass.
Secure a browser session through an identity-aware proxy
Separate identity-provider, proxy, and application sessions while controlling cookies, CSRF, logout, renewal, and origin trust.
Secure browser origin boundaries
Design origins, sessions, cross-origin reads, state changes, frames, messages, and scripts as separate browser security controls.
Separate three different access decisions
Trace authentication, gateway route authorization, and application permission as separate decisions with separate evidence.
Threat-model an identity-aware access path
Trace one protected request, find trust boundaries and bypass paths, and test which access decisions belong at the gateway and application.
Trace an identity-aware application request
Trace DNS, TLS, authentication, session, route, policy, upstream, application authorization, response, and evidence.
Validate JOSE objects safely
Separate JWT claims, JWS signatures, JWE encryption, and JWK key data and apply a fixed validation policy.
24 related terms
Concepts in this topic
Access Token
An access token is a credential that a client presents to a resource server.
Bastion Host
A bastion host is a hardened system that provides controlled administrative access to a more protected network or resource.
Clientless Zero Trust Access
Distinguish browser or native-client access from broad network tunnels and state which protocols still require a local connector.
Context-Aware Proxy
A context-aware proxy is a policy enforcement point placed between a requester and a protected service.
Credential Injection
Credential injection supplies a bounded upstream credential after access policy allows a request.
Gateway Bypass Path
Find every route that reaches a protected origin without the intended identity, policy, and evidence controls.
HTTP Semantics
HTTP semantics define request methods, targets, fields, responses, status codes, authorities, and intermediary behavior.
Identity-Aware Rate Limiting
Identity-aware rate limiting bounds request volume by accountable subject, client, resource, action, and cost.
Insecure Inter-Agent Communication
Authenticate agent messages, bind them to one task and audience, validate content, and preserve actor and delegation evidence.
JSON Web Token (JWT)
Learn how JSON Web Tokens carry signed or encrypted claims, which checks a receiver must make, and how Pomerium uses a signed identity assertion.
Layer-7 Enforcement
Layer 7 enforcement uses protocol facts, such as host, route, method, tool name, and verified identity, to make access decisions.
Named Resource Access
Grant access to one named application or service without extending general reachability to its network or neighboring systems.
Object and Action Authorization
Authorize every application action against the exact object instead of trusting route access, a role, or an object ID.
Per-Request Authorization
Per-request authorization evaluates each action against current identity, resource, policy, and request context immediately before enforcement.
Route
In Pomerium, a route defines how a requester reaches a service behind Pomerium.
Secure Route Selection
Select a route from trusted authority and path data so an attacker cannot redirect policy or credentials to the wrong upstream.
Signed Header
Pomerium's signed header is the X-Pomerium-Jwt-Assertion header.
SSH Protocol
SSH authenticates a server and client, then multiplexes sessions, commands, and forwarding channels over one transport.
Stateless
A stateless service does not keep server-side session state between requests.
Token Exchange
Exchange an incoming security token for narrow target authority while preserving subject, actor, audience, and delegation semantics.
Unexpected Agent Code Execution
Keep model output, tool arguments, generated code, interpreters, and sandboxes from becoming uncontrolled host execution.
Upstream and Downstream
Upstream and downstream describe direction relative to one intermediary, so the reference point must be explicit.
WebSocket Access
WebSocket access starts with an HTTP upgrade and then carries long-lived bidirectional messages on one connection.
Workload Identity
Learn how workload, machine, service, and non-human identities differ from user identity, and how to scope machine-to-machine access.
