Composer 2.4 encrypted auth.json lacks token scope metadata and automatic refresh

Context

Composer 2.4 introduced encrypted auth.json storage, requiring a passphrase to decrypt credentials at runtime. This improves credential confidentiality but does not extend the underlying authentication model to support token scopes or automatic renewal.

Goal

Define a least-privilege authentication workflow for private package repositories where tokens carry explicit scope restrictions and expire on a predictable schedule, while still using the encrypted auth.json format.

Constraints and uncertainty

The current auth.json schema stores tokens as opaque strings under http-basic or gitlab-token keys without scope identifiers. Composer does not inspect token expiry claims, nor does it trigger a refresh flow when a 401 response is received. Expired or over-scoped tokens therefore remain in the file until manually removed, and failed installations surface only generic authentication errors.

Documentation confirms the encryption feature but does not describe a roadmap for scope-aware storage or built-in token lifecycle management.

Questions

1. Is there a supported extension point or plugin interface that allows injecting scope validation and automatic token refresh into Composer's authentication layer without modifying core code?
2. What is the recommended pattern for rotating short-lived, scope-limited tokens in CI/CD pipelines that rely on encrypted auth.json?