9 Commits

Include renames

Author	SHA1	Message	Date
Dan MilneandClaude Opus 4.8	71ee301dd2	Device flow: replay-revocation, user_code CSPRNG, /device rate limit ... More device-flow security-review fixes. Replay-revocation on device_code redemption (was: destroy on use): - Redemption now marks the code redeemed_at and links the issued access/refresh tokens back to it (new oidc_device_code_id FKs, on_delete: :nullify) instead of destroying the row. A replayed redeemed code is detected as reuse — revoking every descended token and returning a distinguishable "already been used" invalid_grant rather than the generic "Invalid device_code" — mirroring the authorization-code reuse semantics (RFC 6749 §4.1.2). The device_code FK is carried forward across refresh rotation so revocation reaches the whole chain. Redeemed codes are reaped by the existing expiry cleanup sweep. user_code CSPRNG (RFC 8628 §6.1): - The 8-char user_code is a credential (type it + Approve mints tokens), so draw it from SecureRandom instead of Ruby's global Mersenne Twister (Array#sample). Rate-limit the /device verification endpoint (RFC 8628 §5.1): - Add the app's standard 10/min limit on show + verify so a signed-in user can't brute-force the short code space to deny or hijack a pending authorization. Also carried in this commit (other agent's working-tree change): - Give each OidcController rate_limit a distinct name: so frequent device polling on the token endpoint no longer shares one counter with (and 429s) unrelated token/refresh/revoke/introspect calls. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_016Q4ATZHoMCWqvSpE2yYoie	2026-07-19 13:38:40 +10:00
Dan MilneandClaude Fable 5	24266872f9	Revoke access tokens too on refresh-token reuse detection ... revoke_family! revoked only the refresh tokens in a rotation family. When reuse of a revoked refresh token was detected (a token-theft signal), the access tokens issued across that chain stayed valid at /userinfo until expiry — up to the access-token TTL — so an attacker holding a stolen access token kept access. revoke_family! now also revokes every access token referenced by the family's refresh tokens. Adds a regression test: rotate once, reuse the revoked token, and assert both the original and rotated-in access tokens are revoked. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-06-11 20:23:17 +10:00
Dan MilneandClaude Opus 4	b7fa49953c	Revoke full token chain on OIDC authorization-code replay ... The replay handler previously used a created_at time-range filter to target access tokens and called update_all(expires_at:), which left revoked_at nil, skipped refresh tokens entirely, and could miss or falsely catch tokens from concurrent flows. Add an oidc_authorization_code FK on both token tables, carry it through refresh-token rotation, and use the association to revoke every descendant via revoke! (which sets revoked_at and cascades access -> refresh). Co-Authored-By: Claude Opus 4 <noreply@anthropic.com>	2026-04-20 17:39:08 +10:00
Dan Milne	93a0edb0a2	StandardRB fixes	2026-01-01 13:29:44 +11:00
Dan Milne	3db466f5a2	Switch Access / Refresh tokens / Auth Code from bcrypt ( and plain ) to hmac. BCrypt is for low entropy passwords and prevents dictionary attacks - HMAC is suitable for 256-bit random data.	2025-12-31 15:48:32 +11:00
Dan Milne	40815d3576	Use SolidQueue in production. Use the find_by_token method, rather than iterating over refresh tokens, as we already fixed for tokens	2025-12-31 14:32:34 +11:00
Dan Milne	cc7beba9de	PKCE is now default enabled. You can now create public / no-secret apps OIDC apps	2025-12-31 09:22:18 +11:00
Dan Milne	99c3ac905f	Add a token prefix column, generate the token_prefix and the token_digest, removing the plaintext token from use.	2025-12-30 09:45:16 +11:00
Dan Milne	ab0085e9c9	More complete oidc	2025-11-18 20:02:45 +11:00