Notifications
Clear all
Topic starter
02/08/2026 12:20 pm
TL;DR: Application capability grants, tsnet, and Funnel can be combined to build a lightweight identity provider that authorises users from tailnet context and supports custom OAuth and OIDC flows, according to Tailscale. The governance question is not whether this works, but which identity and access assumptions break when application identity is embedded into the network layer.
NHIMG editorial — based on content published by Tailscale: Building on Tailscale: How we made a tiny identity provider
Questions worth separating out
A: Security teams should treat network context as part of the authorisation workflow, not as a separate infrastructure concern.
Q: What breaks when dynamic client registration is exposed to too many users or groups?
A: Control over OAuth client creation becomes fragmented, and applications can accumulate unreviewed access paths that are difficult to trace back to accountable owners.
Q: Why do network-aware identity patterns complicate IAM governance?
A: Because the access decision is no longer made only in a central identity provider.
Practitioner guidance
- Map identity decisions to runtime boundaries Inventory every place where application behaviour depends on request identity, capability grants, or network membership.
- Govern dynamic client registration explicitly If applications can register OAuth clients dynamically, define who may do so, what approval is required, and how those registrations are reviewed and revoked.
- Review custom claims before they reach tokens Document every extraClaims field that can alter OAuth or OIDC tokens, then validate whether each claim is necessary, accurate, and aligned with token-minimisation rules.
What's in the full article
Tailscale's full post covers the implementation detail this analysis intentionally leaves for the source:
- The tsnet setup pattern for embedding Tailscale connectivity directly into a Go application
- The .WhoIs call flow that returns user, node, and application capability grant context
- The ACL grant JSON structure that drives admin UI access, dynamic client registration, and custom claims
- The Funnel pattern for exposing public endpoints while keeping /authorize private
👉 Read Tailscale’s build guide for tsnet, grants, and Funnel-based identity flows →
Tailscale-aware identity providers: what changes for IAM teams?
Explore further
02/08/2026 1:21 pm
Identity context is becoming an application runtime control, not just an upstream directory function. This post shows a model where request identity, group grants, and application behaviour are combined inside the service itself. That collapses the old separation between authentication, authorisation, and deployment networking. For IAM teams, the practical conclusion is that policy now travels with the request path, so governance must follow the runtime, not just the directory.
A few things that frame the scale:
- The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to The State of Secrets in AppSec.
- Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap, according to The State of Secrets in AppSec.
A question worth separating out:
A: Public access to an application surface affects reachability, but public exposure of authorisation logic affects who can mint tokens, register clients, or alter trust decisions. The first is a connectivity choice. The second is an identity governance issue that can change the security posture of the whole system.
👉 Read our full editorial: Tailscale-aware identity providers shift OAuth governance inward
