Can Buddy‑Auth safely add an auto‑refresh flow for expired JWTs?

Answer

No, not safely in the current state. Buddy-Auth can support an auto-refresh flow only if the refresh path re-validates identity and current authorization on every use and the :unauthenticated handler is changed to allow silent renewal for API clients. With the existing custom handler that rejects or redirects on expired credentials and an unfinished default refresh design, adding auto-refresh by default would risk privilege escalation and redirect loops.

Confirmed facts

• Buddy-Auth has no built-in auto-refresh flow.
• It relies on a custom :unauthenticated handler that either rejects or redirects when credentials are expired.
• Developers currently expose a separate /refresh endpoint; the default refresh design is unfinished.
• The open design discussion flags the risk of refreshing a token without re-checking scopes.

Likely explanation

A safe auto-refresh is possible in principle only when the refresh operation is treated as a new authorization decision, not as a blind re-sign of prior claims. That means validating the refresh token, checking the current scope/role set against the live authorization store at refresh time, and issuing a new short-lived access token with the same or reduced privileges. The described :unauthenticated handler is not designed for seamless silent refresh; a handler that rejects or redirects cannot transparently attempt a refresh without distinguishing expired access tokens from invalid ones and without avoiding redirect loops for API clients.

Best practice for short-lived access tokens is to keep access tokens short-lived and use a separate, tightly protected refresh token. Auto-refresh should be allowed only for same-scope renewal; elevation or scope change should require re-authentication, which aligns with least-privilege.

Steps needed for this case

1. Verify the :unauthenticated handler can emit a distinct signal for expired vs invalid tokens and can return a non-redirect error for API requests.
2. Review the existing /refresh endpoint to confirm it validates the refresh token, checks current scopes against the live authorization store, issues only short-lived access tokens, and does not allow privilege increase.
3. Enforce strict scope re-validation on every refresh and reject refresh if scopes were reduced or revoked after the original access token was issued.
4. Decouple browser redirect flows from API token renewal to avoid leaking refresh tokens and redirect loops.

Missing diagnostic that changes the recommendation

Does the current /refresh endpoint validate the refresh token against the live authorization store at refresh time and issue a new access token with only the currently granted scopes, with no privilege increase? If not, auto-refresh cannot be made safe without first fixing the refresh endpoint.