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.
Editorial analysis by NHI Mgmt Group, based on content published by Tailscale: “Building on Tailscale: How we made a tiny identity provider”.
Key questions
Q: How should teams govern OAuth when identity context comes from the network layer?
A: Treat the network-attached identity as an input to authorisation, not as a replacement for policy.
Q: Why do application capability grants create governance risk in lightweight IdPs?
A: Because grants can become operational policy when they control admin access, client registration, and token claims.
Q: What breaks when private identity endpoints are exposed too broadly?
A: The authorisation boundary becomes ambiguous, and identity functions that should stay private can be reached from outside the trusted network context.
Practitioner guidance
- Map identity decisions to the tailnet boundary Document where request identity is consumed from the tailnet and where the application makes its own authorisation decision.
- Review application capability grants as policy Treat per-user and per-group grants as governed authorisation logic.
- Separate public and private endpoints Keep the /authorize endpoint and other sensitive identity functions private to the tailnet unless there is a deliberate, documented reason to expose them.
Bottom line: Tailscale-aware identity providers merge connectivity context with OAuth governance, which changes where authorisation decisions are made and reviewed.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
02/08/2026 1:21 pm
Network-attached identity is becoming an authorisation primitive, not just a transport detail. tsnet shows that an application can consume user identity from the tailnet and use it directly in token issuance and client registration decisions. That collapses a boundary many IAM programmes still assume exists between connectivity and identity control. The practical consequence is that identity governance has to extend into network-delivered context, because access decisions now depend on what the tailnet knows at request time.
A question worth separating out:
Q: What is the difference between tailnet identity and application authorisation?
A: Tailnet identity tells the application who or what is making the request within the trusted network context. Application authorisation decides what that identity can do, such as access the admin UI, register an OAuth client, or receive custom claims. Keeping those layers distinct preserves reviewable governance.
👉 Read our full editorial: Tailscale-aware identity providers shift OAuth governance inward