feat(core): expose oidc session uid on ctx.auth

[simeng-li]

Summary

Plumb the access token's sessionUid (already persisted on every session-backed AccessToken model by node-oidc-provider) through koaOidcAuth so route handlers can identify the current OIDC session. Adds an optional sessionUid?: string to the user Auth type and forwards the value verbatim from the verified access token.

This is groundwork for the upcoming isCurrent flag on the GET /api/my-account/sessions response — see GitHub #8681. No consumer reads ctx.auth.sessionUid yet; that lands in the next PR (P1.2).

Testing

Unit tests

Checklist

• .changeset
• unit tests
• integration tests
• necessary TSDoc comments

[github-actions]

COMPARE TO master

Total Size Diff 📈 +874 Bytes

Diff by File

Name	Diff
packages/core/src/middleware/koa-auth/koa-oidc-auth.test.ts	📈 +638 Bytes
packages/core/src/middleware/koa-auth/koa-oidc-auth.ts	📈 +30 Bytes
packages/core/src/middleware/koa-auth/types.ts	📈 +206 Bytes

[darcyYe]

Non-blocking suggestion: the runtime change only sets sessionUid from koaOidcAuth, which matches the P1.1 scope. The type is still a single broad Auth shape though (type: 'user' | 'app'), so sessionUid?: string is now also available at the type level for type: 'app' contexts.

The design note says not to add this to the M2M/app context. If we want the type contract to reflect that more strictly, we could split Auth into a discriminated union, e.g. UserAuth with optional sessionUid / clientId / identityVerified, and AppAuth without sessionUid. Current runtime behavior looks safe, so I’d treat this as a follow-up/nit rather than a blocker.

[wangsijie]

🤖 PR Review

This PR plumbs the OIDC access token's session UID through koaOidcAuth into ctx.auth and adds focused unit coverage for both present and absent values.

• 🔒 Security: clean
• 🏗️ Architecture: clean
• 👨‍💻 Engineering: clean

Verdict: ⚠️ Needs attention

[simeng-li]

Non-blocking suggestion: the runtime change only sets sessionUid from koaOidcAuth, which matches the P1.1 scope. The type is still a single broad Auth shape though (type: 'user' | 'app'), so sessionUid?: string is now also available at the type level for type: 'app' contexts.

The design note says not to add this to the M2M/app context. If we want the type contract to reflect that more strictly, we could split Auth into a discriminated union, e.g. UserAuth with optional sessionUid / clientId / identityVerified, and AppAuth without sessionUid. Current runtime behavior looks safe, so I’d treat this as a follow-up/nit rather than a blocker.

AppAuth is not available for the user account API. So this is not an issue.

[wangsijie]

🤖 PR Review

This PR plumbs the OIDC access token's sessionUid onto ctx.auth as groundwork for upcoming session-aware APIs.

• 🔒 Security: 0 high, 1 medium
• 🏗️ Architecture: clean
• 👨‍💻 Engineering: clean

Verdict: ⚠️ Needs attention

[wangsijie]

🔒 Medium: Adding sessionUid to the shared WithAuthContext lets handlers type-check against ctx.auth.sessionUid even on routes backed by other auth middlewares where that field is never populated at runtime.

[simeng-li]

Keeping sessionUid?: string on the shared Auth type for now. The same shape already carries identityVerified?: boolean and clientId?: string, both of which are populated only by koa-oidc-auth and likewise typed-but-undefined for handlers behind other middlewares. Adding sessionUid follows the established pattern; tightening it (discriminated union over type: 'user' | 'app', or moving it to a separate context decoration) is a wider refactor that touches every ctx.auth consumer in the repo.