It’s at the network level. It will block clients from connecting to the destinations on the network. You don’t need to modify any applications at the destination.
Am I misinterpreting like, the entire body of the article?
> For private services inside your tailnet, like internal tools, implementing auth on every app is overkill. That’s why we developed tsnet, a Go library that embeds Tailscale directly in your applications. This lets you see and react to the identity of every user who makes a request to your app. So, authentication is handled…what about authorization?
The article then proceeds to show how to modify an application using tsnet to embed in the application. Which sounds a whole lot like modifying the application. The point might be that it’s more straightforward to do this then gate behind something like keycloak, but fundamentally it still requires modifying the application
Ah yes. This seems to be something new and entirely optional. They’re saying that it might make sense to some to keep both network and application level authorization defined in one place. Personally, I’m with you in just using a normal SSO solution.
> For private services inside your tailnet, like internal tools, implementing auth on every app is overkill. That’s why we developed tsnet, a Go library that embeds Tailscale directly in your applications. This lets you see and react to the identity of every user who makes a request to your app. So, authentication is handled…what about authorization?
The article then proceeds to show how to modify an application using tsnet to embed in the application. Which sounds a whole lot like modifying the application. The point might be that it’s more straightforward to do this then gate behind something like keycloak, but fundamentally it still requires modifying the application