DXCDT-335: Store access token in OS keyring

[willvedd]

🔧 Changes

Up until now, the Auth0 access token was stored in a local JSON config file. While the token is short-lived, it does possess a wide range of scopes and could be problematic if exposed. A theoretical attack vector could be a malicious package/process traversing a filesystem in hopes of finding an Auth0 CLI configuration file with a valid access token.

Similarly to other secrets in the Auth0 CLI, it is propsed to store the access token in the OS keyring. However, there are OS-specific size limits that we need to be aware of. In order to integrate nicely across all platforms, we are sharding the access token across a number of separate secrets in the keyring.

Not all OSs have a keyring installed by default, notably bare linux distros. In these cases, we continue to write the access token to the local configuration file directly. Presumably, these cases would most likely occur in CI or automated jobs where the process is short-lived and token discarded shortly after use.

Notably, the Github CLI stores their Oauth tokens in a local JSON configuration file much like the current implementation. However, the community has an outstanding request to store in the keyring, much like this PR is attempting to accomplish.

📚 References

• Keyring size limits PR
• Related Github CLI Issue

🔬 Testing

• Several sets of unit tests added to cover numerous situations
• E2E tests passing in CI (no keyring enabled)
• E2E tests pass locally (keyring enabled)
• General manual testing with first-class command and api invocations

📝 Checklist

• All new/changed/fixed functionality is covered by tests (or N/A)
• I have added documentation for all new/changed functionality (or N/A)

[willvedd]

🎉