Identity-Aware Access: SSO for Internal Services Without a VPN

Internal tools have a habit of leaking. A staging dashboard, an admin panel, a metrics UI — someone exposes it "just for the demo," and the only thing standing between it and the internet is an obscure URL. Knowing the URL shouldn't be enough to get a response. The clean answer isn't a VPN for every contractor; it's identity-aware access, where the gateway checks who the caller is before any request reaches your service.

This is the SSO/OIDC side of access control. (If you need certificate-based machine identity instead, that's mutual TLS — a different mechanism for a different problem.)

Per-endpoint auth modes

Every endpoint picks how it's protected, configured under Endpoint Settings → Authentication in the dashboard or via the API. The modes:

• None (Public) — no authentication; for public sites or open webhooks.
• Basic Auth — username and password with bcrypt hashing.
• Bearer / Token — a token in the Authorization or X-Tunnel-Token header; ideal for APIs.
• SSO (Unified RBAC) — OAuth providers with role-based access control.
• Mutual TLS (mTLS) — require a client certificate at the handshake.

On top of the chosen mode you can layer an IP allowlist (IPv4/IPv6 CIDR ranges) and rate limiting, both enforced at the edge before traffic reaches your service. See the Access Controls docs.

Bring your own identity provider

SSO mode speaks OAuth/OIDC, so users sign in with the identity they already have. Supported providers:

• Google — Google Workspace / Gmail.
• GitHub — GitHub accounts and organizations.
• Azure AD — Microsoft Entra ID.
• Okta / Auth0 — enterprise identity platforms.
• Custom OIDC — Keycloak, Authentik, Zitadel, or any OIDC-compliant provider.

Setup is the usual OIDC dance: register a Web Application using the Authorization Code flow in your provider, then point its redirect URL at https://{your-subdomain}.ngris.io/_tunnel_auth/oauth/callback. Full steps are in the SSO / OIDC docs.

From identity to authorization

Authenticating a user is only half the job; you still decide what they may do. When someone signs in via SSO, Ngris matches their OAuth subject identifier — the sub claim for Google, the username for GitHub, oid for Azure — to a client record on the endpoint, then applies Unified RBAC. Roles restrict access by:

• Allowed paths — whitelist URL paths (e.g. /api/*).
• Denied paths — blacklist sensitive paths (e.g. /admin/**).
• Allowed methods — restrict to specific HTTP methods.

Roles are assigned through the endpoint's Memberships tab. So one engineer can read everything while another is confined to a single path, all driven by the identity they logged in with.

Onboarding people the right way

You rarely want an internal tool open to anyone who finds it. Each endpoint has its own clients and a registration policy with three modes: Open (anyone can register), Invite Only (only a valid invite link works), and Requires Approval (register, then wait for an admin). Invite links carry a display name and email, and expire on a schedule you set — 72 hours by default, up to a year. Once a client is authenticated, their metadata is forwarded downstream as HTTP headers so your backend can identify them without an extra lookup. More in the RBAC & OAuth docs.

For org-wide controls — required SSO, redaction defaults, retention — and a broader look at how Ngris secures traffic, see the security overview and the enterprise page.