standard_id 0.34.0 → 0.36.0

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA256:
-  metadata.gz: 984924490081d96a84ec4570541802d70414cac9dcf9dd325b8aba6ee7af7be2
-  data.tar.gz: c132d58daeea53090156fe42bfd3b6a7b8d8a2393d7ae7a3766e0c4ece0e8a6d
+  metadata.gz: 7dd8850abb672f638f6db5cf4d60ae8ec64b26bdb8d5835405c72e7bebc4d800
+  data.tar.gz: 69575f6669362c905ed16059f35f15044f1ee2bbade449b6dc5c62bfd93caeb5
 SHA512:
-  metadata.gz: 65dac8337e2bfa0784d43308d4c29eeeb8208c3b06b721a3f1a2f040eec1916ba35c00b8e69945f72c80a7240b95cb17ed4bf46c6939fe8c78508c44bf3363b9
-  data.tar.gz: eb1acc6703201fa5955494aec635f1821ea4d9689b49f73703736f853deb166b5eeaec1adcb20fe79c083f15903301e60829da0497ec0e138af49d2f406e4b02
+  metadata.gz: 87ed7e67e16666c2c576a2e7bb55e43ff2a861ecf93c824d5995da4d8f383d09f4bb60e8b389e9821e2d85acfb849690548cc0e6fbfabaa3e73d0f02dd44015c
+  data.tar.gz: 9036f22d16ee08ac97a4e5d6ae46d8c6fc7c63130da4ed66a815dfef2b21ecce787f576cc2127dbd6040405e6a6dbd2f4f71c5303d1c6e803770347af6d85b9f

data/CHANGELOG.md

@@ -7,6 +7,52 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
 
 ## [Unreleased]
 
+## [0.36.0] - 2026-08-04
+
+### Security
+
+- **`SESSION_VALIDATING` now carries the `account:` its subscribers guard on, so `AccountStatus` and `AccountLocking` finally stop a LIVE authenticated request.** Both concerns subscribe to `OAUTH_TOKEN_ISSUING`, `SESSION_CREATING` and `SESSION_VALIDATING` and branch on `event[:account]&.inactive?` / `&.locked?`. Neither publisher of `SESSION_VALIDATING` ever sent an `account:` — `Web::AuthenticationGuard#emit_session_validating` and `Api::AuthenticationGuard#emit_session_validating` both published `session:` alone. `Events#enrich_payload` injects `:current_account`, a *different* key, so `event[:account]` was `nil` and that leg of both guards never fired.
+
+  That it was an omission rather than a design is plain from the sibling emitters in the same two files: `emit_session_validated` and `emit_session_expired` each pass `account:`. Only the *validating* hook — the one that runs before the request is allowed to proceed, and therefore the only one of the three that can stop it — left it out.
+
+  **Upgrade implication — expect previously-working sessions and tokens to start failing. That is the fix.** Three shapes were getting through and now do not:
+
+  1. **API bearer tokens, the big one.** `AccountStatusSubscriber` / `AccountLockingSubscriber` revoke `account.sessions.active` on `deactivate!` / `lock!`, but an access token is a stateless JWT with no `Session` row — revoking sessions does nothing to it. Until its `exp`, `SESSION_VALIDATING` was the only thing that could refuse it, and it was inert. Any client holding an access token minted before the account went bad kept working; it now gets `AccountDeactivatedError` / `AccountLockedError` on the next request.
+  2. **A status change that skips the callbacks** — `update_all`, `update_column`, a data migration, direct SQL, an admin bulk action. No `ACCOUNT_DEACTIVATED` / `ACCOUNT_LOCKED` event fires, so no session revocation happens, and the browser session stayed live until it expired.
+  3. **A session minted after the account went bad by a path that emits no `SESSION_CREATING`.** `Web::SessionManager#load_session_from_remember_token` calls `create_browser_session` directly and publishes nothing, so remember-me re-auth walked straight past the sign-in guard.
+
+  Hosts that lock or deactivate accounts should expect support traffic from users whose sessions used to survive. `sidekick-web`'s `LockAccountModal` copy — *"The user will be immediately locked out / All active sessions will be terminated"* — is now true rather than aspirational.
+
+  **No new query on either hot path.** The web guard reads the `:account` association only when it is already loaded (`SessionManager` loads the session with `eager_load(:account)`) and otherwise falls back to a single indexed `find_by` — it must never lazily touch the association, because several consumers run `strict_loading_by_default` and this emitter is on the path of *every* authenticated request, where a `StrictLoadingViolationError` would turn an inert guard into a 500. It also runs *before* the blank/expired/revoked checks, so it handles a nil session. The API guard threads its `SessionManager` through to reuse the memoized, strict-loading-cleared `#current_account` that `emit_session_validated` resolves anyway.
+
+  The spec that let this survive for so long asserted enforcement by publishing `SESSION_VALIDATING` **by hand** with the very key the real publisher omitted — proof that the subscriber reacts to a correctly-shaped payload, not that any caller produces one. Those examples now drive the real guards over real HTTP requests (`spec/requests/standard_id/live_session_account_guard_spec.rb`), and were confirmed to fail with the `account:` key removed.
+
+  Tracked in rarebit-one/rarebit-ops#306.
+
+### Added
+
+- **`POST /oauth/revoke` logs a warning when `revocation_scope: :grant` resolves a presented `jti` to no `RefreshToken`.** Under `:grant`, presenting an access token is a deliberate no-op that still answers 200 (RFC 7009 §2.2) — correct, because access tokens are stateless and never persisted, but until now completely silent. A client that only ever presents access tokens looked like it was revoking when it was not. As `:grant` is adopted across the estate, post-flip no-ops need to be visible. Emitted via `StandardId.logger&.warn`, consistent with the existing `revocation_scope` fallback warning. No behaviour change. Relates to rarebit-one/rarebit-ops#304.
+
+## [0.35.0] - 2026-07-31
+
+### Security
+
+- **A refresh token is now refused when its parent session is revoked or expired.** `Oauth::RefreshTokenFlow` validated the `RefreshToken` row only — found, not revoked, not expired — and never consulted the session it belongs to.
+
+  So "revoking a session ends that session's access" was not a property of the gem. It was an emergent consequence of every caller reaching for `Session#revoke!` (a transaction that ALSO does `refresh_tokens.active.update_all(revoked_at:)`) rather than the obvious-looking `session.update!(revoked_at: ...)`, which revokes the session row and leaves its refresh tokens live. Two apps wrote the second form independently and shipped it (rarebit-one/nutripod-web#1100, luminalityai/luminality-web#1048), because the natural spec asserts the session's own `revoked_at` — exactly the half that does work.
+
+  On the device path that meant a refresh-token holder kept minting access tokens after the user had explicitly signed that device out. Checking the parent in the flow makes the property true by construction: it now holds however the session was revoked — `revoke!`, a bare `update!`, a bulk `update_all`, a DBA, a data fix — and covers session expiry too.
+
+  **Unaffected:** refresh tokens with no session (`session_id` nil) — the machine-to-machine shape, including `client_credentials`. There is no parent to outlive, so nothing is checked. No configuration flag was added because no flow in the gem legitimately needs a refresh to outlive its session; every token that carries a `session_id` was minted against that session, and rotation carries the same `session_id` forward.
+
+  The refusal reuses the existing `invalid_grant` / `"Refresh token is no longer valid"` response verbatim (RFC 6749 §5.2). A distinct error would be an oracle — it would tell a holder that the token itself is still good and only the session was pulled.
+
+  The parent session is fetched by `eager_load` in the same query as the token row, so the hot `/oauth/token` path gains no extra round trip.
+
+  Tracked in rarebit-one/rarebit-ops#297.
+
+- **`POST /oauth/introspect` reports the same refresh token as `active: false`.** The RFC 7662 endpoint (off by default, behind `config.oauth.introspection_enabled`) checked the `RefreshToken` row and not its session, so it had the identical gap. Left alone it would have reported `active: true` for a token `/oauth/token` now refuses — introspection contradicting the endpoint it describes. Access tokens are unchanged and still introspect as active until their `exp`; that documented limit is unaffected, because they are stateless and carry no `sid`.
+
 ## [0.34.0] - 2026-07-31
 
 ### Added

data/app/controllers/standard_id/api/oauth/introspections_controller.rb

@@ -32,8 +32,12 @@ module StandardId
       # lifetime.
       #
       # Refresh tokens ARE persisted (as `SHA256(jti)`), so those are checked
-      # against the row: a revoked or expired refresh token introspects as
-      # inactive, correctly and immediately.
+      # against the row AND against the parent session: a refresh token that is
+      # itself revoked or expired — or whose session is — introspects as
+      # inactive, correctly and immediately. That second half matters because
+      # the session can be revoked without the cascade ever running (a bare
+      # `update!`, a bulk `update_all`); see Oauth::RefreshTokenFlow and
+      # rarebit-one/rarebit-ops#297.
       class IntrospectionsController < BaseController
         public_controller
 
@@ -86,8 +90,21 @@ module StandardId
           return render_inactive if payload.nil?
 
           # Persisted refresh tokens are checkable; access tokens are not.
-          persisted = StandardId::RefreshToken.find_by_jti(payload[:jti].to_s) if payload[:jti].present?
+          #
+          # eager_load the parent session in the same query: the answer must
+          # match what Oauth::RefreshTokenFlow would do with the same token, and
+          # that flow refuses a refresh whose session is revoked or expired
+          # (rarebit-one/rarebit-ops#297). Reporting `active: true` here for a
+          # token /oauth/token would refuse would make introspection an
+          # authority that disagrees with the endpoint it describes.
+          #
+          # A nil session means no parent — the machine-to-machine shape — and
+          # is not a reason to call the token inactive.
+          if payload[:jti].present?
+            persisted = StandardId::RefreshToken.eager_load(:session).find_by_jti(payload[:jti].to_s)
+          end
           return render_inactive if persisted && !persisted.active?
+          return render_inactive if persisted&.session && !persisted.session.active?
 
           render json: active_response(payload, persisted), status: :ok
         end

data/app/controllers/standard_id/api/oauth/revocations_controller.rb

@@ -93,10 +93,27 @@ module StandardId
             .where(token_digest: StandardId::RefreshToken.digest_for(jti))
             .includes(:session, :account)
             .first
+          # No persisted grant for this jti. Per RFC 7009 §2.2 the endpoint
+          # still answers 200, and for an access token that is the correct
+          # no-op (access tokens are stateless JWTs and are never persisted).
+          # But under :grant the no-op is otherwise completely silent, so a
+          # client that only ever presents access tokens looks like it is
+          # revoking when it is not. Log it so post-flip no-ops are visible.
+          if record.nil?
+            StandardId.logger&.warn(
+              "[StandardId::Revocations] revocation_scope=:grant — presented jti " \
+              "resolved to no RefreshToken for account #{payload[:sub]}; nothing " \
+              "revoked (RFC 7009 §2.2 still returns 200). This is expected when " \
+              "an access token is presented; present the refresh token for " \
+              "revocation to take effect."
+            )
+            return
+          end
+
           # A jti that resolves to another subject's grant must never revoke
           # it — the token was signature-verified, but bind the two identities
           # anyway rather than trusting a single claim.
-          return if record.nil? || record.account_id.to_s != payload[:sub].to_s
+          return if record.account_id.to_s != payload[:sub].to_s
 
           refresh_tokens_revoked = record.revoke_family!
 

data/lib/standard_id/api/authentication_guard.rb

@@ -3,7 +3,7 @@ module StandardId
     class AuthenticationGuard
       def require_session!(session_manager, request: nil)
         api_session = session_manager.current_session
-        emit_session_validating(api_session, request)
+        emit_session_validating(api_session, request, session_manager: session_manager)
 
         if api_session.blank?
           raise StandardId::NotAuthenticatedError, "Invalid or missing access token"
@@ -55,10 +55,16 @@ module StandardId
         end
       end
 
-      def emit_session_validating(api_session, request)
+      # Mirrors emit_session_validated/expired below. The session_manager is
+      # threaded through so resolve_account takes its memoized, strict-loading-
+      # cleared #current_account rather than a lazy `api_session.account` —
+      # this emitter runs on every authenticated request, before the
+      # blank/expired/revoked checks, so it must not be able to raise.
+      def emit_session_validating(api_session, request, session_manager: nil)
         StandardId::Events.publish(
           StandardId::Events::SESSION_VALIDATING,
-          session: api_session
+          session: api_session,
+          account: resolve_account(api_session, session_manager)
         )
       end
 

data/lib/standard_id/oauth/refresh_token_flow.rb

@@ -47,7 +47,11 @@ module StandardId
         # once all pre-jti tokens have expired (refresh_token_lifetime after deploy).
         return if jti.blank?
 
-        @current_refresh_token_record = StandardId::RefreshToken.find_by_jti(jti)
+        # eager_load (not includes/lazy) so the parent session arrives in the
+        # SAME query via a LEFT OUTER JOIN. #validate_parent_session! below
+        # reads it on every refresh, and /oauth/token is a hot path — a lazy
+        # `.session` would add a second SELECT per request.
+        @current_refresh_token_record = StandardId::RefreshToken.eager_load(:session).find_by_jti(jti)
 
         unless @current_refresh_token_record
           raise StandardId::InvalidGrantError, "Refresh token not found"
@@ -63,6 +67,41 @@ module StandardId
         unless @current_refresh_token_record.active?
           raise StandardId::InvalidGrantError, "Refresh token is no longer valid"
         end
+
+        validate_parent_session!
+      end
+
+      # Refuse a refresh whose parent session is no longer active.
+      #
+      # Without this, "revoking a session ends that session's access" was not a
+      # property of the gem at all — it was an emergent consequence of every
+      # caller reaching for Session#revoke! (a transaction that ALSO does
+      # `refresh_tokens.active.update_all(revoked_at:)`) rather than the
+      # obvious-looking `session.update!(revoked_at:)`, which revokes the
+      # session row and leaves its refresh tokens live. Two apps wrote the
+      # second form independently and shipped it, because a spec asserting the
+      # session's own `revoked_at` passes against the buggy code.
+      #
+      # Checking the parent here makes the property true by construction: it
+      # holds however the session was revoked — `revoke!`, a bare `update!`, a
+      # bulk `update_all`, a DBA, a data fix — and it covers expiry as well.
+      # See rarebit-one/rarebit-ops#297.
+      #
+      # A refresh token with no session (`session_id` nil) is unaffected: that
+      # is the machine-to-machine shape (client_credentials and any other grant
+      # the gem issues without persisting a session), where there is no parent
+      # to outlive and nothing to check.
+      #
+      # The message is deliberately IDENTICAL to the inactive-token case above.
+      # A distinct error would be an oracle: it would tell an attacker holding a
+      # stolen refresh token that the token itself is still good and only the
+      # session was pulled. RFC 6749 §5.2 wants `invalid_grant` either way.
+      def validate_parent_session!
+        session = @current_refresh_token_record.session
+        return if session.nil?
+        return if session.active?
+
+        raise StandardId::InvalidGrantError, "Refresh token is no longer valid"
       end
 
       # Atomically revoke the current token as part of rotation.

data/lib/standard_id/version.rb

@@ -1,3 +1,3 @@
 module StandardId
-  VERSION = "0.34.0"
+  VERSION = "0.36.0"
 end

data/lib/standard_id/web/authentication_guard.rb

@@ -27,7 +27,8 @@ module StandardId
       def emit_session_validating(browser_session, request)
         StandardId::Events.publish(
           StandardId::Events::SESSION_VALIDATING,
-          session: browser_session
+          session: browser_session,
+          account: resolve_account(browser_session)
         )
       end
 
@@ -47,6 +48,37 @@ module StandardId
           expired_at: browser_session.expires_at
         )
       end
+
+      # SESSION_VALIDATING is the only one of the three emitters that runs
+      # BEFORE the blank/expired/revoked checks, so it cannot borrow the
+      # assumptions its siblings rely on:
+      #
+      #   * the session may be nil (the blank? check has not run yet), so a
+      #     bare `browser_session.account` would NoMethodError; and
+      #   * it also fires for sessions the host app installed into
+      #     `Current.session` itself, which — unlike SessionManager's
+      #     `eager_load(:account)` path — carries no loaded :account
+      #     association. Several consumers run `strict_loading_by_default`
+      #     (jumpdrive-web, luminality-web), where a lazy `record.account`
+      #     raises StrictLoadingViolationError. Since this emitter is on the
+      #     path of EVERY authenticated request, that would turn an inert
+      #     guard into a 500.
+      #
+      # So: read the association only when it is already loaded, and otherwise
+      # fall back to the same single indexed lookup Api::AuthenticationGuard's
+      # resolve_account uses. Neither branch can raise under strict loading.
+      def resolve_account(browser_session)
+        return if browser_session.blank?
+
+        if browser_session.respond_to?(:association) && browser_session.association(:account).loaded?
+          return browser_session.account
+        end
+
+        account_id = browser_session.account_id if browser_session.respond_to?(:account_id)
+        return if account_id.blank?
+
+        StandardId.account_class.find_by(id: account_id)
+      end
     end
   end
 end

metadata

@@ -1,7 +1,7 @@
 --- !ruby/object:Gem::Specification
 name: standard_id
 version: !ruby/object:Gem::Version
-  version: 0.34.0
+  version: 0.36.0
 platform: ruby
 authors:
 - Jaryl Sim