1. What is a Proxy?
A proxy is a server that sits between a client and another service.
Instead of this:
User → Application
you get this:
User → Proxy → Application
The proxy receives the user request, checks or modifies it, and then forwards it to the real backend service.
2. Types of Proxies
| Proxy type | Direction | Main use |
|---|---|---|
| Forward proxy | Client → Internet | Used by users/devices to access external websites through a controlled gateway |
| Reverse proxy | Internet/User → Internal app | Protects backend apps and exposes a controlled public endpoint |
| Load-balancing proxy | User → Multiple backend servers | Distributes traffic across app servers |
| API gateway | Client/API consumer → APIs | Authentication, rate limits, API routing, request validation |
| Identity-aware proxy | User → Protected app | Allows access only after identity and policy checks |
Most production “proxy in front of app” designs are reverse proxies.
flowchart LR
U[User Browser] --> P[Reverse Proxy]
P --> A1[App Server 1]
P --> A2[App Server 2]
P --> A3[App Server 3]
P --> L[Logs / Monitoring]
P --> W[WAF / Security Rules]
3. What is Identity-Aware Proxy?
An Identity-Aware Proxy, often shortened to IAP, is a proxy that checks who the user is before allowing access to an application.
A normal reverse proxy usually asks:
“Where should I route this request?”
An Identity-Aware Proxy asks:
“Who is this user, are they allowed, is their device trusted, and should this request reach the app?”
Google Cloud has a product literally called Identity-Aware Proxy, which creates a central authorization layer for HTTPS applications and lets teams use application-level access control instead of depending mainly on network-level firewalls. Google describes IAP as a cloud-native alternative to traditional VPNs for apps on services such as Cloud Run, App Engine, Compute Engine, and GKE. (Google Cloud Documentation)
In AWS and Azure, the same pattern exists, but the product names are different:
| Cloud | IAP-style service |
|---|---|
| Google Cloud | Identity-Aware Proxy |
| AWS | AWS Verified Access, or ALB authentication with Cognito/OIDC |
| Azure | Microsoft Entra Application Proxy, App Service Authentication, Microsoft Entra Private Access |
4. Why Use Identity-Aware Proxy?
Without IAP:
flowchart LR
U[User] --> VPN[VPN / Network Access]
VPN --> NET[Private Network]
NET --> A[Internal App]
NET --> DB[Other Internal Systems]
The problem: once a user gets into the network, they may have broader network reach than they actually need.
With IAP:
flowchart LR
U[User] --> IAP[Identity-Aware Proxy]
IAP -->|Allowed request only| A[Specific App]
IAP -.->|Denied| D[Blocked]
IDP[Identity Provider] --> IAP
POLICY[Access Policy] --> IAP
DEVICE[Device Posture] --> IAP
The user gets access to one application, not the whole network.
Key Benefits
| Benefit | Explanation |
|---|---|
| No broad VPN access | Users access only the app they are authorized for |
| Central authentication | Login is handled by IdP such as Google, Microsoft Entra ID, Okta, Cognito, Auth0 |
| Central authorization | Rules are managed outside the application |
| MFA support | You can require multi-factor authentication before app access |
| Group-based access | Allow only specific teams, such as DevOps, Finance, HR, Admin |
| Device-aware access | Some platforms can check device compliance, risk, or security posture |
| Better audit logs | Access attempts are logged before traffic reaches the backend |
| Legacy app protection | Old apps can be protected without rewriting app authentication logic |
5. How Identity-Aware Proxy Works
At a high level:
sequenceDiagram
participant User as User Browser
participant IAP as Identity-Aware Proxy
participant IdP as Identity Provider
participant Policy as Policy Engine
participant App as Backend App
User->>IAP: Request app.example.com
IAP->>IdP: Redirect user to login
IdP->>User: Login page / MFA
User->>IdP: Credentials + MFA
IdP->>IAP: Token / identity claims
IAP->>Policy: Evaluate user, group, device, request
Policy-->>IAP: Allow or deny
alt Allowed
IAP->>App: Forward request
App-->>IAP: Response
IAP-->>User: App response
else Denied
IAP-->>User: Access denied
end
IAP Decision Inputs
| Input | Example |
|---|---|
| User identity | rajesh@example.com |
| Group membership | DevOps, Admins, Finance |
| Device posture | Managed laptop, compliant device, antivirus healthy |
| Location / IP | Company region, trusted IP range |
| MFA status | MFA completed or not |
| Request details | HTTP method, path, hostname |
| Time | Business hours only |
| Risk score | Suspicious login, impossible travel, compromised device |
6. Normal Proxy vs Identity-Aware Proxy
| Feature | Reverse Proxy | Identity-Aware Proxy |
|---|---|---|
| Routes traffic | Yes | Yes |
| TLS termination | Yes | Yes |
| Load balancing | Often | Sometimes |
| User authentication | Usually no | Yes |
| Group-based authorization | Usually no | Yes |
| MFA support | Usually no | Yes, through IdP |
| Device-aware policy | No | Often yes |
| Zero Trust friendly | Limited | Yes |
| Best for internal apps | Sometimes | Yes |
7. Core Architecture Components
flowchart TB
subgraph UserSide[User Side]
U[User Browser]
D[User Device]
end
subgraph ControlPlane[Identity and Policy Control Plane]
IDP[Identity Provider]
MFA[MFA]
DIR[User / Group Directory]
POL[Policy Engine]
LOG[Audit Logs]
end
subgraph ProxyLayer[Identity-Aware Proxy Layer]
IAP[IAP / Access Proxy]
WAF[Optional WAF]
TLS[TLS Certificate]
end
subgraph AppLayer[Private Application Layer]
APP[Internal Web App]
API[Internal API]
DB[(Database)]
end
U --> IAP
D --> IAP
IAP --> IDP
IDP --> MFA
IDP --> DIR
IAP --> POL
IAP --> LOG
IAP --> WAF
IAP --> TLS
IAP --> APP
APP --> API
API --> DB
Components Table
| Component | Purpose |
|---|---|
| User/browser | Makes the request |
| Identity provider | Authenticates user |
| Policy engine | Decides whether access is allowed |
| IAP/proxy | Enforces the decision |
| Backend app | Receives only allowed traffic |
| Audit logs | Record allow/deny events |
| WAF | Optional extra layer for web attacks |
| DNS | Routes app domain to proxy |
| TLS certificate | Secures HTTPS traffic |
8. Tools to Implement Identity-Aware Proxy
Cloud-Native Tools
| Platform | Tool | Best use case |
|---|---|---|
| Google Cloud | Identity-Aware Proxy | Native IAP for Google Cloud apps and some on-prem/private apps |
| AWS | AWS Verified Access | Identity-aware access to corporate/private apps without VPN |
| AWS | Application Load Balancer authentication | Basic web authentication using Cognito or OIDC before forwarding to targets |
| Azure | Microsoft Entra Application Proxy | Publish private/on-prem web apps with Entra ID authentication |
| Azure | Azure App Service Authentication / Easy Auth | Add authentication to App Service, Azure Functions, APIs with little/no app code |
| Azure | Microsoft Entra Private Access | Broader Zero Trust private access and VPN replacement pattern |
AWS Verified Access provides secure access to corporate applications without VPN and evaluates requests in real time. AWS also supports authentication directly at Application Load Balancer using Cognito or OIDC before routing to applications. (AWS Documentation)
Microsoft Entra Application Proxy provides secure remote access to on-premises web applications, while Azure App Service Authentication, also called Easy Auth, provides built-in authentication and authorization for App Service and Azure Functions. (Microsoft Learn)
Open-Source / Vendor Tools
| Tool | Type | Notes |
|---|---|---|
oauth2-proxy | Open-source reverse proxy | Protects apps using OAuth2/OIDC authentication |
| Pomerium | Identity-aware proxy | Zero Trust, context-aware access proxy |
| Cloudflare Access | SaaS / ZTNA | Identity-based access to private apps |
| Teleport Application Access | Access platform | Identity-aware access for apps, SSH, Kubernetes, databases |
| NGINX + OIDC module/lua | Reverse proxy pattern | Powerful but needs careful configuration |
| Envoy + external authorization | Service mesh / proxy | Advanced pattern for microservices |
| Traefik ForwardAuth | Reverse proxy middleware | Can delegate authentication to another service |
| Authentik | Identity provider + proxy features | Useful in self-hosted environments |
| Authelia | Authentication gateway | Common for homelab/internal app protection |
| Keycloak | Identity provider | Often paired with oauth2-proxy, NGINX, Pomerium, or custom apps |
oauth2-proxy describes itself as a flexible open-source tool that can work as a standalone reverse proxy or middleware for OAuth2/OIDC authentication. Pomerium describes itself as an identity and context-aware reverse proxy, Cloudflare Access is Cloudflare’s ZTNA product, and Teleport Application Access supports secure access to private applications. (GitHub)
9. Example IAP Use Cases
| Use case | Example |
|---|---|
| Protect internal dashboard | Grafana, Kibana, Prometheus, Jenkins |
| Protect admin console | /admin, Django admin, Rails admin |
| Protect staging app | staging.example.com |
| Replace VPN for web apps | Give users access to one app, not the network |
| Protect legacy app | App has weak/no auth, IAP adds modern SSO |
| Contractor access | Allow external partner only to one app |
| Production support access | Require MFA and device compliance for prod tools |
| Secure APIs | Require identity before API requests reach backend |
10. Example Architecture: Protecting Grafana with IAP
flowchart LR
Dev[Developer] --> DNS[dashboard.company.com]
DNS --> IAP[Identity-Aware Proxy]
IAP --> IdP[Okta / Entra ID / Google / Cognito]
IAP --> Policy[Access Policy: DevOps group only]
IAP --> Grafana[Private Grafana]
Grafana --> Metrics[(Metrics DB)]
IAP --> Logs[Audit Logs]
Policy idea:
Allow access only when:
- user is authenticated
- user belongs to DevOps group
- MFA is completed
- device is compliant
- request is for dashboard.company.com
11. Implement Identity-Aware Proxy in AWS
AWS does not call its service “IAP.” The closest AWS-native equivalent is AWS Verified Access.
AWS Option A: AWS Verified Access
Use this when:
| Requirement | Good fit? |
|---|---|
| Private corporate app access | Yes |
| Replace VPN for web apps | Yes |
| Identity-aware access | Yes |
| Device-aware access | Yes, depending on provider |
| App should stay private in VPC | Yes |
| Need policy-based access | Yes |
AWS Verified Access evaluates each request using trust data from identity/device providers and policies. Verified Access endpoints represent applications, endpoints can inherit group policy, and app-specific endpoint policies can also be attached. Policies are written in Cedar and evaluated against identity/device trust data. (AWS Documentation)
AWS Verified Access Architecture
flowchart TB
U[Remote User] --> DNS[app.company.com]
DNS --> VA[AWS Verified Access Endpoint]
subgraph AWS[AWS Account / Region]
VA --> VG[Verified Access Group]
VG --> POL[Cedar Access Policy]
VA --> ALB[Internal Application Load Balancer]
ALB --> EC2[Private EC2 / ECS / EKS App]
end
IDP[IAM Identity Center / OIDC IdP] --> VA
DEVICE[Device Trust Provider] --> VA
VA --> LOGS[CloudWatch / S3 Logs]
AWS Verified Access Components
| Component | Meaning |
|---|---|
| Verified Access instance | Main container for Verified Access configuration |
| Trust provider | Source of identity or device trust data |
| Verified Access group | Logical group of protected apps |
| Verified Access endpoint | Represents one protected application |
| Policy | Cedar rule deciding allow/deny |
| Target app | ALB, network interface, or private application endpoint |
| Logs | Access records for auditing and troubleshooting |
Verified Access trust providers send user/device context to AWS Verified Access; this context can include user attributes such as email or group membership and device information such as patch or antivirus posture. AWS supports IAM Identity Center as a user-identity trust provider, and it also supports OIDC-based providers. (AWS Documentation)
AWS Verified Access Step-by-Step
Step 1: Prepare the private application
Example target:
Private EC2/ECS/EKS app
↓
Internal Application Load Balancer
↓
AWS Verified Access
↓
Public HTTPS hostname
Your backend app should not be directly public. Keep it in private subnets or restrict direct access using security groups.
Step 2: Configure identity provider
Common choices:
| IdP | Example |
|---|---|
| AWS IAM Identity Center | Native AWS workforce identity |
| Okta | OIDC/SAML enterprise login |
| Auth0 | OIDC provider |
| Microsoft Entra ID | OIDC/SAML provider |
| Amazon Cognito | User pool / OIDC-style login |
For the AWS-native path, use IAM Identity Center as a trust provider. AWS notes that IAM Identity Center for Verified Access must be an AWS Organizations instance, not a standalone account instance. (AWS Documentation)
Step 3: Create Verified Access trust provider
Conceptually:
Trust Provider:
Type: User identity
Provider: IAM Identity Center or OIDC
Policy reference name: idp
The policy reference name matters because it becomes the context key used inside Cedar policies. AWS documentation says that if the policy reference name is idp123, the context key becomes context.idp123. (AWS Documentation)
Step 4: Create Verified Access instance
Verified Access Instance:
Trust provider: idp
Logging: enabled
Step 5: Create Verified Access group
Verified Access Group:
Name: internal-apps
Policy: shared access rules for many apps
Step 6: Create endpoint for the application
Verified Access Endpoint:
Domain: app.company.com
Type: load balancer
Target: internal ALB
Certificate: ACM public certificate
Group: internal-apps
AWS describes a Verified Access endpoint as representing an application. Each endpoint is associated with a Verified Access group and can inherit the group policy. (AWS Documentation)
Step 7: Add access policy
Example Cedar policy for IAM Identity Center group + verified email:
permit(principal, action, resource)
when {
context.idp.groups has "c242c5b0-6081-1845-6fa8-6e0d9513c107" &&
context.idp.user.email.verified == true
};
Replace:
idp
with your actual policy reference name.
Replace:
c242c5b0-6081-1845-6fa8-6e0d9513c107
with your real IAM Identity Center group ID.
AWS recommends using IAM Identity Center group IDs rather than group names so the policy does not break when a group name changes. (AWS Documentation)
Step 8: Configure DNS
Create DNS record:
app.company.com → Verified Access endpoint domain
Step 9: Test access
| Test | Expected result |
|---|---|
| Unauthenticated user opens app | Redirected to IdP |
| Authenticated but wrong group | Denied |
| Correct group + verified email | Allowed |
| Direct backend ALB access | Blocked by security group |
| Policy removed | Denied by default |
AWS says Verified Access denies application requests by default until a policy is defined.
12. AWS Option B: Application Load Balancer Authentication
Use this when you want simpler authentication at the load balancer level.
flowchart LR
User[User] --> ALB[Public ALB with Auth Rule]
ALB --> Cognito[Amazon Cognito / OIDC IdP]
ALB --> TG[Target Group]
TG --> App[EC2 / ECS / EKS App]
AWS Application Load Balancer can authenticate users using corporate or social identities before routing requests to applications. It can integrate with Amazon Cognito or an OIDC provider. (AWS Documentation)
ALB Auth vs Verified Access
| Feature | ALB Authentication | AWS Verified Access |
|---|---|---|
| Basic login before app | Yes | Yes |
| OIDC/Cognito support | Yes | Yes |
| Central Zero Trust policy | Limited | Stronger |
| Device posture | No / limited | Supported via trust providers |
| Private-app VPN replacement | Not as complete | Yes |
| Best for | Simple web login | Enterprise app access |
AWS ALB Authentication Steps
- Create an Amazon Cognito user pool or use OIDC provider.
- Create an Application Load Balancer.
- Create HTTPS listener.
- Add listener rule: authenticate first, then forward to target group.
- Configure callback URL in IdP/Cognito.
- Restrict backend security group so only ALB can reach the app.
- Test login and logout behavior.
AWS recommends special CloudFront forwarding behavior if CloudFront is placed in front of an authenticated ALB, including forwarding all request headers to avoid cached authenticated responses being served after session expiry. (AWS Documentation)
13. Implement Identity-Aware Proxy in Azure
Azure has several IAP-style patterns. Choose based on where the app runs.
Azure Decision Table
| App location | Best Azure option |
|---|---|
| Azure App Service / Azure Functions | App Service Authentication / Easy Auth |
| On-premises private web app | Microsoft Entra Application Proxy |
| Broad private access / VPN replacement | Microsoft Entra Private Access |
| Kubernetes / containers | Ingress + Entra ID/OIDC, or external IAP tool |
| Public app needing WAF + auth | App Gateway/Front Door + app-level auth or Easy Auth |
14. Azure Option A: Microsoft Entra Application Proxy
Use this when your app is on-premises or private, and you want remote users to access it without opening inbound firewall ports.
Microsoft Entra Application Proxy provides secure remote access to on-premises web apps. Microsoft says users can access on-premises apps through an external URL or internal application portal after SSO to Microsoft Entra ID. (Microsoft Learn)
Azure Application Proxy Architecture
flowchart TB
U[Remote User] --> URL[External URL]
URL --> ENTRA[Microsoft Entra ID Login]
ENTRA --> CAP[Conditional Access / MFA]
CAP --> APPSVC[Application Proxy Cloud Service]
subgraph PrivateNetwork[Private Network / On-Prem]
CONN[Private Network Connector]
APP[Internal Web App]
end
APPSVC --> CONN
CONN --> APP
ENTRA --> LOGS[Sign-in Logs / Audit Logs]
How Azure Application Proxy Works
sequenceDiagram
participant User
participant Entra as Microsoft Entra ID
participant Proxy as App Proxy Service
participant Connector as Private Network Connector
participant App as On-Prem App
User->>Proxy: Open external app URL
Proxy->>Entra: Redirect for sign-in
Entra->>User: Login + MFA / Conditional Access
User->>Proxy: Sends token after successful sign-in
Proxy->>Connector: Forward authorized request
Connector->>App: Send request to internal app
App-->>Connector: App response
Connector-->>Proxy: Return response
Proxy-->>User: Show app
Microsoft explains that Application Proxy includes a cloud service and a private network connector installed on an on-premises server. The connector uses outbound connections, so you do not need to open inbound firewall ports. (Microsoft Learn)
Azure Application Proxy Step-by-Step
Step 1: Prepare prerequisites
| Requirement | Example |
|---|---|
| Microsoft Entra tenant | Your Azure/Entra organization |
| App Proxy license support | Depends on tenant licensing |
| Windows Server for connector | Server with network access to internal app |
| Internal app URL | http://intranet.local |
| External app URL | https://intranet-company.msappproxy.net or custom domain |
| Users/groups | Finance, DevOps, Support |
| Conditional Access | MFA, compliant device, location rule |
Step 2: Install private network connector
Install the Microsoft Entra private network connector on a Windows Server that can reach the internal application.
The connector should be placed close to the app network. For production, use at least two connectors for high availability.
Microsoft notes that connectors are lightweight agents installed inside the private network. Connectors create outbound connections to Application Proxy and Private Access services, and connector groups can be used for high availability and traffic routing. (Microsoft Learn)
Step 3: Publish the internal application
In Microsoft Entra admin center:
Enterprise applications
→ New application
→ On-premises application
→ Configure Application Proxy
Example settings:
| Setting | Example |
|---|---|
| Name | Internal Grafana |
| Internal URL | http://grafana.internal:3000 |
| External URL | https://grafana-company.msappproxy.net |
| Pre-authentication | Microsoft Entra ID |
| Connector group | Production-Connectors |
Microsoft’s tutorial for Application Proxy covers installing/verifying the connector and adding an on-premises application to the Microsoft Entra tenant. (Microsoft Learn)
Step 4: Assign users or groups
Assign only the users/groups that need access:
Users and groups:
- DevOps
- SRE
- Platform Admins
Step 5: Add Conditional Access
Example policy:
For app: Internal Grafana
Grant access only when:
- User is in DevOps group
- MFA completed
- Device is compliant
- Sign-in risk is low
Microsoft says Application Proxy can use Microsoft Entra Conditional Access, allowing richer policy controls before connections to the private network are established. (Microsoft Learn)
Step 6: Test
| Test | Expected result |
|---|---|
| User not assigned | Access denied |
| Assigned user without MFA | MFA challenge |
| Assigned user with MFA | App opens |
| Connector stopped | App unavailable |
| Internal app down | Proxy reachable but backend fails |
15. Azure Option B: Azure App Service Authentication / Easy Auth
Use this when your application runs on:
Azure App Service
Azure Functions
Azure Web App
Azure App Service provides built-in authentication and authorization, commonly called Easy Auth, and Microsoft says it can help secure web apps, REST APIs, mobile backends, and functions with little or no code. (Microsoft Learn)
Easy Auth Architecture
flowchart LR
User[User Browser] --> AppSvc[Azure App Service]
AppSvc --> Entra[Microsoft Entra ID / Other IdP]
AppSvc --> App[Your Application Code]
App --> API[Backend API]
Easy Auth Step-by-Step
- Open your Azure App Service.
- Go to Authentication.
- Add identity provider.
- Choose Microsoft Entra ID or another IdP.
- Configure unauthenticated requests:
- Redirect to login, or
- Return HTTP 401.
- Restrict app access to selected users/groups through Entra enterprise application assignment.
- Add Conditional Access if required.
- Test login.
Easy Auth vs Application Proxy
| Feature | Easy Auth | Entra Application Proxy |
|---|---|---|
| Protect Azure App Service | Excellent | Not usually needed |
| Protect on-prem app | No | Yes |
| Requires connector | No | Yes |
| Little/no app code | Yes | Yes |
| Best for | Azure-hosted apps | Private/on-prem apps |
16. Azure Option C: Microsoft Entra Private Access
Use this for a broader VPN-replacement architecture.
Microsoft Entra Private Access is part of Global Secure Access and provides granular access to private resources. Microsoft describes it as a way to replace VPN-style access using Conditional Access controls. (Microsoft Learn)
flowchart TB
User[User Device] --> GSA[Global Secure Access Client]
GSA --> Entra[Microsoft Entra ID]
Entra --> CA[Conditional Access]
GSA --> PrivateAccess[Microsoft Entra Private Access]
subgraph PrivateNetwork[Private Network]
Connector[Private Network Connector]
App1[Private Web App]
App2[Private TCP App]
DB[Internal Resource]
end
PrivateAccess --> Connector
Connector --> App1
Connector --> App2
Connector --> DB
Use this when you need access to multiple private apps/resources, not only one web app.
17. Advanced Identity-Aware Proxy Patterns
Pattern 1: Protect only /admin
flowchart LR
User --> Proxy
Proxy -->|/public| PublicApp[Public App]
Proxy -->|/admin requires login| IAP[IAP Auth]
IAP --> AdminApp[Admin Backend]
Example:
| Path | Auth required? |
|---|---|
/ | No |
/docs | No |
/admin | Yes |
/metrics | Yes |
/api/internal | Yes |
Pattern 2: Multiple apps, one access layer
flowchart TB
User --> IAP[Central IAP]
IAP --> Grafana[Grafana]
IAP --> Jenkins[Jenkins]
IAP --> Kibana[Kibana]
IAP --> Admin[Admin Portal]
IDP[Identity Provider] --> IAP
Policy[Central Policies] --> IAP
Pattern 3: Device-aware access
flowchart LR
User --> IAP
IAP --> IdP[Identity Provider]
IAP --> Device[Device Trust Provider]
IAP --> Policy[Policy Engine]
Policy --> Decision{Allow?}
Decision -->|Yes| App
Decision -->|No| Deny[Access Denied]
Policy:
Allow only when:
- user is in Admin group
- MFA is complete
- laptop is managed
- device risk is low
Pattern 4: IAP + WAF
flowchart LR
User --> WAF[Web Application Firewall]
WAF --> IAP[Identity-Aware Proxy]
IAP --> App[Private App]
Use this when the app is exposed to the internet and you also want protection against common web attacks.
18. Security Best Practices
| Area | Best practice |
|---|---|
| Identity | Use SSO with Entra ID, Okta, Google, Cognito, or IAM Identity Center |
| MFA | Require MFA for sensitive apps |
| Groups | Grant access through groups, not individual users |
| Least privilege | Give users access only to required apps |
| Backend exposure | Do not allow direct public access to backend app |
| TLS | Use HTTPS everywhere |
| Logging | Enable access logs and sign-in logs |
| WAF | Add WAF for public-facing apps |
| Device posture | Require compliant devices for production/admin apps |
| Break-glass access | Maintain emergency admin access with strong controls |
| Session duration | Use shorter sessions for sensitive apps |
| Secrets | Do not pass long-lived secrets in headers |
| Headers | Trust identity headers only from the proxy, never from public internet |
| Testing | Test denied cases, not only allowed cases |
19. Common Mistakes
| Mistake | Why it is dangerous |
|---|---|
| Backend app is still public | Attackers can bypass IAP |
| Trusting user-supplied headers | User can spoof identity headers |
| No MFA | Stolen password can become full access |
| Assigning access to everyone | Defeats the purpose of IAP |
| Using passthrough authentication accidentally | Proxy may not authenticate users first |
| No logs | Hard to investigate incidents |
| No health checks | Outages become confusing |
| Long sessions | Compromised sessions last too long |
| No separate admin policy | Admin apps need stricter policy |
For Azure Application Proxy specifically, Microsoft warns that choosing passthrough preauthentication does not provide the same benefit as Microsoft Entra preauthentication, because anonymous traffic is not blocked before reaching the backend path. (Microsoft Learn)
20. Troubleshooting Checklist
| Symptom | Possible cause | Fix |
|---|---|---|
| User gets access denied | Not assigned to app/group | Add user/group |
| Infinite login loop | Redirect URI mismatch | Fix callback/external URL |
| App loads but assets fail | App uses absolute internal URLs | Configure link translation / app base URL |
| Backend unavailable | Connector/ALB/app down | Check health and routing |
| Everyone can access | Policy too broad | Tighten groups/MFA/device rules |
| Direct backend access works | Backend exposed publicly | Restrict security group/firewall |
| User authenticated but app does not know user | Missing identity headers/token handling | Configure trusted headers or app token validation |
| AWS policy denies everyone | Wrong policy reference name | Match Cedar context key to trust provider policy reference |
| Azure connector offline | Connector service stopped/outbound blocked | Check connector health and outbound 80/443 |
21. Recommended Learning Path
flowchart TD
A[Learn proxy basics] --> B[Learn reverse proxy]
B --> C[Learn SSO: SAML / OIDC]
C --> D[Learn MFA and Conditional Access]
D --> E[Learn IAP architecture]
E --> F[Implement one small internal app]
F --> G[Add group-based policy]
G --> H[Add device/MFA policy]
H --> I[Add logging and alerting]
I --> J[Roll out production pattern]
22. Final Summary
An Identity-Aware Proxy is a secure gatekeeper in front of your application. It checks identity, group membership, MFA, device posture, and policy before allowing traffic to reach the backend.
For production:
| Environment | Recommended implementation |
|---|---|
| Google Cloud | Google Cloud IAP |
| AWS private apps | AWS Verified Access |
| AWS simple web auth | ALB authentication with Cognito/OIDC |
| Azure App Service | App Service Authentication / Easy Auth |
| Azure on-prem/private web apps | Microsoft Entra Application Proxy |
| Azure VPN replacement | Microsoft Entra Private Access |
| Self-hosted/Kubernetes | oauth2-proxy, Pomerium, NGINX + OIDC, Envoy, Traefik ForwardAuth |
The core idea is simple:
Do not expose the app directly.
Expose the proxy.
Authenticate the user.
Evaluate policy.
Forward only allowed requests.
Log everything.
