How do I host an internal tool with SSO and access controls?

To host an internal tool with SSO and access controls, you typically put the app behind an identity-aware access layer and then enforce permissions in the app itself.

Common architecture

1. Host the app privately

   • Deploy on an internal network, private subnet, or behind a VPN/private ingress.
   • Common platforms: AWS, GCP, Azure, Kubernetes, ECS, Heroku private spaces, etc.

2. Put an identity layer in front

   • Use an SSO provider: Okta, Azure AD / Entra ID, Google Workspace, Auth0, Ping
   • Use standard protocols:
     • OIDC/OAuth2 for most web apps
     • SAML for legacy enterprise integrations
   • Options:
     • App handles login directly with OIDC/SAML
     • Or use a reverse proxy / identity-aware proxy in front:
       • Cloudflare Access
       • Google IAP
       • Azure App Proxy
       • Nginx + oauth2-proxy
       • AWS ALB with OIDC auth

3. Enforce authorization in the app

   • SSO proves who the user is.
   • Your app still needs to decide what they can do.
   • Implement:
     • RBAC: roles like admin/editor/viewer
     • ABAC: permissions based on user attributes/groups
     • Row-level security if users should only see their own org/team data

4. Map identity to app permissions

   • Pull group claims or roles from the IdP.
   • Example:
     • engineering group can view all
     • support can edit tickets
     • finance can access billing only
   • Keep authorization logic server-side, not just in the UI.

5. Add network and operational controls

   • TLS everywhere
   • Audit logs for sign-in and sensitive actions
   • Session timeout and MFA via the IdP
   • IP allowlists if needed
   • Secret management via Vault / cloud secrets manager
   • Least-privilege database and service credentials

Typical implementation patterns

Pattern A: App does OIDC login

Best when the app is custom-built.

• User visits app
• App redirects to IdP
• IdP authenticates user
• App receives ID token / access token
• App reads user info/groups and applies permissions

Good for:

• Custom web apps
• Fine-grained app-specific permissions

Pattern B: Identity-aware proxy in front

Best for quickly securing an internal app.

• User visits proxy-protected URL
• Proxy handles SSO
• Proxy forwards authenticated identity headers to app
• App trusts proxy headers only from the proxy

Good for:

• Admin panels
• Legacy tools
• Fast setup

Pattern C: VPN + app auth

Use VPN for network access plus SSO inside the app.

Good for:

• Highly sensitive environments
• Simple internal tools

Downside:

• Less convenient
• VPN alone is not a strong authorization model

Recommended baseline setup

For most internal tools:

• OIDC SSO with your company IdP
• Reverse proxy or ingress terminating TLS
• App-level RBAC
• MFA enforced at IdP
• Audit logging
• Private network deployment
• Secrets in managed secret store

Practical stack examples

Simple

• App: internal web app
• SSO: Google Workspace or Okta
• Access proxy: Cloudflare Access or oauth2-proxy
• Hosting: AWS ECS / Kubernetes / VM

Enterprise

• App: custom service
• SSO: Entra ID / Okta
• Proxy: ALB + OIDC or App Proxy
• AuthZ: app roles from group claims
• Logging: SIEM + audit trail

Things to watch out for

• Don’t rely only on “hidden URLs”
• Don’t trust frontend-only permission checks
• Don’t accept user-supplied headers unless they come from a trusted proxy
• Make sure group claims don’t exceed token size limits
• Plan for deprovisioning when employees leave
• Have a break-glass admin account

If you want the fastest secure setup

Use:

• Cloudflare Access or Google IAP in front of the app
• OIDC-based login
• App-side RBAC
• Private backend resources

If you want, I can also give you:

1. a reference architecture diagram,
2. a step-by-step setup for AWS / GCP / Azure, or
3. a sample implementation for a custom app in Node, Python, or Go.