@broberg/sso 0.6.1 → 0.8.0

package/README.md

@@ -323,3 +323,29 @@ What happens: a verified token → `revokeSubBefore(sub, iat)` → from then on
 **Nothing arrives until BID has registered your URL** — mounting it early is safe (ship dark). Tell broberg-id the exact URL once it is deployed.
 
 **The cost:** one store lookup per request that goes through `attach`/`require`.
+
+## «Log ud» in your app (changed in 0.7.0)
+
+**`GET /logout` now logs the user out of YOUR app only, and shows BID's login dialog.** It clears the app's session and sends the browser to `<mount>/login?prompt=login`; BID then shows its dialog even though the user is still signed in to BID. The user can pick another account or just sign in again. Their BID session, and every other app, are untouched: logging out of BID itself is BID's own «Log ud» (owner decision D-376ffa), and «Log ud overalt» is the button in BID for ending everything.
+
+Up to 0.6.x, `/logout` sent the user to BID's end-session endpoint, which also ended the BID session. Keep that behaviour with:
+
+```ts
+ssoRoutes({ logout: "central" });
+```
+
+`/login?prompt=login` and `/login?prompt=none` are passed on to BID; any other prompt is dropped.
+
+## email_verified on the session (since 0.7.0)
+
+`getSession(c).email_verified` is `true` or `false` when BID said so, and absent when it did not. Sessions minted before 0.7.0 have no such field; treat absent as not verified.
+
+> **On BID today, `email` and `email_verified` are NOT signed.** BID's ID token does not carry them — measured by broberg-id on 20 Sep 2026 against the real service: the token holds `acr · at_hash · aud · auth_time · exp · iat · iss · nonce · sid · sub`, and email + email_verified exist only in the `/oauth2/userinfo` response, which is plain HTTP with no signature. `email_verified === true` is still the right thing to require before linking on an address, but it is BID's word over TLS, not a signed claim.
+>
+> **If a decision must rest on a signed identity, bind on `sub`** (`session.sub`) — the ID token signs it, and the package refuses a userinfo answer whose `sub` differs. helpdesk moved its account linking from email to `sub` for exactly this reason.
+
+## Which claims were signed — `unverifiedClaims` (since 0.8.0)
+
+`completeLogin()` returns `unverifiedClaims: string[]` beside `claims`: the claims that came from the unsigned userinfo response and not from the signed ID token, sorted. Against BID today it is `["email", "email_verified", "name", …]`. An empty list means everything in `claims` was signed, or userinfo was not reached.
+
+When both sources carry a claim, **the signed token's value wins** and the claim is not listed. Before 0.8.0 userinfo was spread over the token, so an issuer whose userinfo disagreed with its own token had the unsigned value win. Against BID this changes nothing today — the two never overlap on email — so for BID it is a hardening, not a fix.

package/dist/hono.cjs

@@ -360,18 +360,19 @@ function createSsoClient(config, options = {}) {
   }
   async function withUserInfo(claims, accessToken) {
     const doc = await discovery();
-    if (!doc.userinfo_endpoint) return claims;
+    if (!doc.userinfo_endpoint) return { claims, unverifiedClaims: [] };
     const res = await fetchImpl(doc.userinfo_endpoint, {
       headers: { authorization: `Bearer ${accessToken}` }
     });
-    if (!res.ok) return claims;
+    if (!res.ok) return { claims, unverifiedClaims: [] };
     const info = await res.json();
     if (info.sub !== claims.sub) {
       throw new SsoError(
         `userinfo describes ${String(info.sub)} but the ID token is for ${claims.sub} \u2014 refusing to merge another user's profile onto this session.`
       );
     }
-    return { ...claims, ...info, sub: claims.sub };
+    const unverifiedClaims = Object.keys(info).filter((k) => k !== "sub" && info[k] !== void 0 && !(k in claims)).sort();
+    return { claims: { ...info, ...claims, sub: claims.sub }, unverifiedClaims };
   }
   return {
     discovery,
@@ -443,8 +444,10 @@ function createSsoClient(config, options = {}) {
         );
       }
       const claims = await verifyIdToken(body.id_token, { nonce });
+      const merged = body.access_token ? await withUserInfo(claims, body.access_token) : { claims, unverifiedClaims: [] };
       return {
-        claims: body.access_token ? await withUserInfo(claims, body.access_token) : claims,
+        claims: merged.claims,
+        unverifiedClaims: merged.unverifiedClaims,
         idToken: body.id_token,
         ...body.access_token ? { accessToken: body.access_token } : {},
         ...body.refresh_token ? { refreshToken: body.refresh_token } : {}
@@ -680,7 +683,7 @@ function ssoRoutes(options = {}) {
   app.get("/login", async (c) => {
     const prompt = c.req.query("prompt");
     const start = await client.beginLogin(
-      prompt === "none" ? { prompt: "none" } : {}
+      prompt === "none" || prompt === "login" ? { prompt } : {}
     );
     const tx = JSON.stringify({
       state: start.state,
@@ -740,7 +743,9 @@ function ssoRoutes(options = {}) {
       iat: Math.floor(Date.now() / 1e3),
       ...result.claims.email ? { email: result.claims.email } : {},
       ...result.claims.name ? { name: result.claims.name } : {},
-      ...result.claims.picture ? { picture: result.claims.picture } : {}
+      ...result.claims.picture ? { picture: result.claims.picture } : {},
+      // Only when BID actually said so — absent means "not stated", never false.
+      ...typeof result.claims.email_verified === "boolean" ? { email_verified: result.claims.email_verified } : {}
     };
     c.header(
       "Set-Cookie",
@@ -778,6 +783,9 @@ function ssoRoutes(options = {}) {
       cookieHeader(idTokenCookie, "", { maxAge: 0, secure: isSecure(c) }),
       { append: true }
     );
+    if ((options.logout ?? "app") === "app") {
+      return c.redirect(`${loginPath}/login?prompt=login`, 302);
+    }
     return c.redirect(await client.logoutUrl(idTokenHint ? { idTokenHint } : {}), 302);
   });
   const attach = async (c, next) => {