fix(auth): retry on 401 invalid_client by reloading device registration from SQLite#116
Conversation
…on from SQLite When kiro-cli re-login rotates device registration (client_id/client_secret), the gateway's in-memory credentials become stale. Previously only 400 (invalid_grant) triggered a SQLite reload and retry. Now 401 (invalid_client) also triggers the same recovery path, reloading both token and device registration from SQLite before retrying. This prevents permanent auth failure requiring a container restart after kiro-cli re-login.
|
Thanks for the PR! 🎉 Before merge, we need a one-time CLA confirmation. Full CLA text: Please reply once with: You need to write once, all further messages from me can be ignored. |
|
I have read the CLA and I accept its terms |
I have read the CLA and I accept its terms |
|
I have read the CLA and I accept its terms |
Problem
When
kiro-cli loginis run while the gateway container is already running, the device registration (client_id/client_secret) in SQLite gets rotated. The gateway's in-memory credentials become stale.Previously, only HTTP 400 (
invalid_grant— stale refresh_token) triggered a SQLite reload and retry. But a rotated device registration returns HTTP 401 (invalid_client— stale client_secret), which was not caught — causing permanent auth failure until the container was restarted.Error sequence observed:
401 invalid_client(stale client_secret in memory)ValueError→ returns HTTP 500 to clientsFix
_refresh_token_aws_sso_oidc(): now retries on both400and401by reloading all credentials (token + device registration) from SQLiteget_access_token()graceful degradation: also handles401in the fallback pathTesting
test_refresh_token_aws_sso_oidc_retries_on_401_invalid_client— verifies 401 triggers SQLite reload and successful retry