Eclipse Secure Storage ↔ OS Credential Store: Least‑Privilege and Expired Credential Handling

Direct answer

Eclipse Secure Storage does not automatically detect expired credentials or prompt for refresh on its own. Expiration handling and token renewal must be implemented by the plugin that stores the credential. Provider migration from the file-based store to an OS credential store will require the master password to decrypt existing entries before they are re-encrypted, but Eclipse does not enforce automatic revocation when the underlying OS token expires.

Confirmed facts

• Secure Storage API has no expiration metadata on entries. There is no built-in expiry field, so Eclipse cannot detect an expired token and cannot prompt for refresh without plugin logic.
• Least-privilege is enforced at the API level. Only bundles with the appropriate Secure Storage access rights can read/write specific entries. Any authorized bundle can read any entry it is authorized for; the model is application-level, not per-field policy.
• Revocation is manual. Eclipse provides no automatic revocation when an OS keychain token expires or is removed. The stale entry remains in Secure Storage until a plugin deletes or updates it, or the user removes it via Preferences > General > Security > Secure Storage.
• OS keychain providers delegate encryption to the OS. The macOS Keychain, Windows Credential Manager and Linux Secret Service providers typically do not use the Eclipse master password for new entries.

Likely explanation for provider change prompts

When the provider is changed via Preferences > General > Security > Secure Storage, Eclipse must re-encrypt existing entries for the new provider. If the new provider is an OS keychain, Eclipse will prompt for the current master password to decrypt the file-based data before storing it in the OS store. The exact prompt wording and timing can vary by Eclipse release and by platform-specific keychain approval dialogs. This is a migration decryption step, not a continuous master-password enforcement for the OS provider.

What you can do in this case

1. Verify current provider: Open Preferences > General > Security > Secure Storage and note the active provider.
2. Check for expiration support: Inspect an entry’s properties. No expiration field is present in Secure Storage.
3. Implement plugin-side refresh: On read, check the token’s expiry claim or timestamp, and if expired, prompt the user and write a new value back via the Secure Storage API.
4. Manual revocation: Delete or invalidate via the Secure Storage preference page or programmatically with the Secure Storage API. Deleting an entry causes subsequent API reads to fail until the plugin recreates it.

Assumptions and uncertainty: Provider migration prompt behavior may change between Eclipse releases. OS keychain integration relies on platform APIs; on macOS Keychain Access may require user approval for access, affecting automated migration. If the master password is lost, file-based entries cannot be recovered; a secure storage reset is required.

One diagnostic detail that changes the recommendation: Eclipse version and the exact provider name currently in use. The prompt logic for provider migration and OS keychain access dialogs differ across 4.30+ releases and across Windows Credential Manager vs macOS Keychain vs Linux Secret Service.