[hujincalrin41]

What

The UI had no way to sign anyone in. The UI server put an administrator token on every API call it forwarded, so opening its address was enough to be admin, and there was no login page to speak of.

This gives each way in an address of its own:

Address	Who	Enabled by
/login — the default page, Sign in with Microsoft	employees, with their M365 account	server.authorization-url … server.client-secret
/login/admin — a password form, not linked from the login page	whoever runs the server	server.admin-password
/login/token — paste an access token this server issued	whoever runs the server	always available

The application is no longer an entry point: without a session it redirects to /login. The UI server adds no credentials of its own. Which ways exist is asked of the server at runtime (GET /auth/providers), so one UI build follows any deployment's configuration.

Microsoft sign-in runs through the server: it redirects to the provider, redeems the code itself and sets the session cookie, so the client secret never reaches the browser.

Server side

Accepting an identity provider's tokens needed more than an entry point:

• The static JWKS file and OIDC discovery now coexist. They were mutually exclusive: a JWKS file, once configured, was used for every issuer, so a deployment could trust its own instances or an identity provider, never both. Routing is by whether the issuer is registered in the file.
• The caller resolves through an ordered claim chain — email, preferred_username, upn, sub — because Entra ID omits email unless it is configured as an optional claim. All four are looked up as the user's email; the authorization model is untouched.
• Discovery is cached per issuer and every call to the provider is bounded. An unreachable provider answers 401 naming the issuer instead of a bodyless 500.
• Entra's {tenantid} issuer template is compared segment-wise, which multi-tenant endpoints advertise literally.
• The session cookie is one a browser keeps: Secure only when the browser is on HTTPS, and SameSite=Lax rather than Strict — the browser returns from the provider on a cross-site navigation, exactly the request a Strict cookie is withheld on.
• The URL transcoder passes a redirect back instead of following it, and ends a bodyless response on its headers. It followed the sign-in redirect itself and relayed the provider's error page as a 400.
• A refused authorization code names the provider's error code (invalid_client, AADSTS7000222), which is what separates an expired secret from a mismatched redirect URI or a replayed code; the full description is logged at warn.

Deployment

deploy-uc.sh derives what the token check needs from the four Microsoft settings — the audience always, the issuer when the authorization URL states it unambiguously — and prints what it added. It starts the UI alongside the server, and warns before rendering secrets over a file that git tracks. Both deployment guides document the Entra setup, including what the client secret's expiry breaks and how to rotate it without losing a sign-in; the Chinese guide had no sign-in chapter at all.

Tests

Server 83 (dual trust chains, identity resolution, issuer templates, discovery caching, hosted login, administrator sign-in configured and not, token sign-in, providers), UI 82 across 22 suites including the route table. javafmtCheckAll, yarn test:format and yarn build are clean.

Verified against a real Entra tenant end to end: the redirect carries the registered client id and callback, and a signed-in user's catalog and table lists are filtered by their grants.

Note for review

This touches JwksOperations and AuthService, which #15 also changes. Whichever lands second will need a rebase there; the rest of this change does not overlap.