Version Packages

[github-actions]

This PR was opened by the Changesets release GitHub action. When you're ready to do a release, you can merge this and the packages will be published to npm automatically. If you're not ready to do a release yet, that's fine, whenever you add more changesets to main, this PR will be updated.

Releases

@seamless-auth/core@0.19.1

Patch Changes

• 0314dfa: Check a silently refreshed access token against authServerIssuer. The silent refresh in ensureCookies now verifies the token it returns, but it checked iss against authServerUrl even when authServerIssuer was set, so an app reaching the auth server at another URL (the local Docker stack from the host) answered 401 on every silent refresh and signed the user out. EnsureCookiesOptions and the Express createEnsureCookiesMiddleware take an optional authServerIssuer, and the adapters pass their configured one.

• ca8fa4a: Verify the access token a silent refresh returns before issuing cookies from it. ensureCookies refreshes an expired session on the auth routes and wrote the auth API's response straight into the access cookie, while every other flow that issues a session (login, OTP, OAuth, magic link, and the explicit /refresh route) first checks the token against the auth server's JWKS and confirms it names the same user as the body. The access cookie is signed with the application's own secret and its roles are trusted on every later request, so a refresh response that did not come from the auth server could become a trusted session. The silent refresh now runs the same check and answers 401, clearing the session cookies, when it fails. The session id is now read from the signed token's sid claim, as the other flows do.

  EnsureCookiesOptions and the Express createEnsureCookiesMiddleware take a new optional accessTokenAudience, the audience user access tokens are issued for. The adapters pass their configured audience. Code that calls ensureCookies or createEnsureCookiesMiddleware directly should pass it too; it defaults to authServerUrl.

@seamless-auth/express@0.19.1

Patch Changes

• 0314dfa: Check a silently refreshed access token against authServerIssuer. The silent refresh in ensureCookies now verifies the token it returns, but it checked iss against authServerUrl even when authServerIssuer was set, so an app reaching the auth server at another URL (the local Docker stack from the host) answered 401 on every silent refresh and signed the user out. EnsureCookiesOptions and the Express createEnsureCookiesMiddleware take an optional authServerIssuer, and the adapters pass their configured one.

• ca8fa4a: Verify the access token a silent refresh returns before issuing cookies from it. ensureCookies refreshes an expired session on the auth routes and wrote the auth API's response straight into the access cookie, while every other flow that issues a session (login, OTP, OAuth, magic link, and the explicit /refresh route) first checks the token against the auth server's JWKS and confirms it names the same user as the body. The access cookie is signed with the application's own secret and its roles are trusted on every later request, so a refresh response that did not come from the auth server could become a trusted session. The silent refresh now runs the same check and answers 401, clearing the session cookies, when it fails. The session id is now read from the signed token's sid claim, as the other flows do.

  EnsureCookiesOptions and the Express createEnsureCookiesMiddleware take a new optional accessTokenAudience, the audience user access tokens are issued for. The adapters pass their configured audience. Code that calls ensureCookies or createEnsureCookiesMiddleware directly should pass it too; it defaults to authServerUrl.

• Updated dependencies [0314dfa]

• Updated dependencies [ca8fa4a]

  • @seamless-auth/core@0.19.1

@seamless-auth/fastify@0.10.1

Patch Changes

• 0314dfa: Check a silently refreshed access token against authServerIssuer. The silent refresh in ensureCookies now verifies the token it returns, but it checked iss against authServerUrl even when authServerIssuer was set, so an app reaching the auth server at another URL (the local Docker stack from the host) answered 401 on every silent refresh and signed the user out. EnsureCookiesOptions and the Express createEnsureCookiesMiddleware take an optional authServerIssuer, and the adapters pass their configured one.

• ca8fa4a: Verify the access token a silent refresh returns before issuing cookies from it. ensureCookies refreshes an expired session on the auth routes and wrote the auth API's response straight into the access cookie, while every other flow that issues a session (login, OTP, OAuth, magic link, and the explicit /refresh route) first checks the token against the auth server's JWKS and confirms it names the same user as the body. The access cookie is signed with the application's own secret and its roles are trusted on every later request, so a refresh response that did not come from the auth server could become a trusted session. The silent refresh now runs the same check and answers 401, clearing the session cookies, when it fails. The session id is now read from the signed token's sid claim, as the other flows do.

  EnsureCookiesOptions and the Express createEnsureCookiesMiddleware take a new optional accessTokenAudience, the audience user access tokens are issued for. The adapters pass their configured audience. Code that calls ensureCookies or createEnsureCookiesMiddleware directly should pass it too; it defaults to authServerUrl.

• Updated dependencies [0314dfa]

• Updated dependencies [ca8fa4a]

  • @seamless-auth/core@0.19.1

@seamless-auth/nextjs@0.3.1

Patch Changes

• 0314dfa: Check a silently refreshed access token against authServerIssuer. The silent refresh in ensureCookies now verifies the token it returns, but it checked iss against authServerUrl even when authServerIssuer was set, so an app reaching the auth server at another URL (the local Docker stack from the host) answered 401 on every silent refresh and signed the user out. EnsureCookiesOptions and the Express createEnsureCookiesMiddleware take an optional authServerIssuer, and the adapters pass their configured one.

• ca8fa4a: Verify the access token a silent refresh returns before issuing cookies from it. ensureCookies refreshes an expired session on the auth routes and wrote the auth API's response straight into the access cookie, while every other flow that issues a session (login, OTP, OAuth, magic link, and the explicit /refresh route) first checks the token against the auth server's JWKS and confirms it names the same user as the body. The access cookie is signed with the application's own secret and its roles are trusted on every later request, so a refresh response that did not come from the auth server could become a trusted session. The silent refresh now runs the same check and answers 401, clearing the session cookies, when it fails. The session id is now read from the signed token's sid claim, as the other flows do.

  EnsureCookiesOptions and the Express createEnsureCookiesMiddleware take a new optional accessTokenAudience, the audience user access tokens are issued for. The adapters pass their configured audience. Code that calls ensureCookies or createEnsureCookiesMiddleware directly should pass it too; it defaults to authServerUrl.

• Updated dependencies [0314dfa]

• Updated dependencies [ca8fa4a]

  • @seamless-auth/core@0.19.1