@broberg/sso 0.7.0 → 0.8.0

package/README.md

@@ -338,4 +338,14 @@ ssoRoutes({ logout: "central" });
 
 ## 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. **Bind access to an email address only when it is `true`** — e.g. `session.email === "cb@broberg.ai" && session.email_verified === true`. Sessions minted before 0.7.0 have no such field; treat absent as not verified.
+`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 } : {}