[gmann14]

Fixes #109

@mostlygeek, this is the PR you asked for on #109.

Clients that ask for a refresh token the standard way, by adding offline_access to the scope (OIDC Core 1.0 section 11), get error=invalid_scope back from /authorize, so the login fails before it reaches the token endpoint. BookLore is one of these clients.

This adds offline_access to openIDSupportedScopes. /authorize now accepts it, and both /.well-known/openid-configuration and /.well-known/oauth-authorization-server list it in scopes_supported. The scope is stored with the request and shows up in introspection like any other scope. Nothing else reads it.

What doesn't change

Refresh token issuance. The token endpoint already returns a refresh token for every authorization code grant, whether or not the client asks for offline_access (30-day lifetime, single use, held in memory). After this change, a client that asks for offline_access gets exactly what a client that doesn't ask has always got. TestOfflineAccessScope runs authorize, token and refresh with and without the scope and checks that both get a working refresh token, so a future change to when refresh tokens are issued will have to update that test on purpose.

Client authentication, Funnel rejection at /authorize, and scope case-sensitivity are also unchanged. OFFLINE_ACCESS in upper case is still rejected.

Spec note on consent

Section 11 says the OP must obtain consent before returning a refresh token for offline access, unless other conditions permit it, and that refresh tokens may also be issued in other contexts. tsidp has no consent step and already issues refresh tokens to every registered client. I read the admin's decision to register the client, plus the user being signed in to the tailnet, as those other conditions. That matches how tsidp behaves today; this PR only stops rejecting clients that ask. If you'd prefer tsidp to issue refresh tokens only when offline_access is requested, that would break clients that rely on getting one without asking, so I've left it out of this change.

Two smaller notes:

• Refresh tokens live in memory, so "offline" access ends when tsidp restarts.
• This doesn't make BookLore work on its own. BookLore is a single-page app and also needs public clients (tsidp appears to require client secrets #174, Support public oidc clients (who don't support secrets) #182).

On the configurable extraScopes idea from the issue and #176: I kept this to the one scope the OIDC spec defines, since every client means the same thing by it. A configurable list could sit on top of this default.

Testing

• TestValidateScopes: openid offline_access and openid email profile offline_access are accepted; OFFLINE_ACCESS is rejected.
• TestScopeHandling: an offline_access case through the code exchange.
• TestOfflineAccessScope (new): authorize, token and refresh through serveAuthorize and serveToken, for openid, openid offline_access and all four scopes. Checks the code is issued, the scopes are stored, a refresh token is returned, and the refreshed token keeps the scopes.
• TestScopesSupportedMetadata (new): both discovery documents list openid email profile offline_access.
• The cases that request offline_access fail on main and pass with the change. gofmt -l ., go vet ./..., go test ./... and go test -race ./server are clean.

Claude Code also ran the real server handler on a loopback port, with the LocalAPI WhoIs call stubbed the same way server/helpers_test.go does it, and went through the flow with curl. On main, /authorize with scope=openid offline_access redirected to the client with error=invalid_scope. With this change it returned a code, /token returned an ID token, access token and refresh token, introspection showed scope: "openid offline_access", the refresh grant worked, and reusing the old refresh token returned invalid_grant.

I used Claude Code to help write this change and the tests, and it also ran them.

[jentfoo]

Looks reasonable to me, I don't think this needs a config flag.