@yacaovsnc , @AlexRukhlin , as we discussed via email (during course of Issue #85 ), there are numerous benefits to fully embracing OAuth2 for authentication in TEE 14.0.4+ instead of automatically creating and relying on a Personal Access Token (PAT):
Already doing one OAuth2 authentication against Azure Active Directory (AAD)
OAuth2 tokens, unlike PATs, can remain in memory only and do not have to be persisted to Eclipse Secure Storage and/or to Credentials.xml; this is ideal for security conscious users like myself who never saved VSTS alternate credentials with TEE 14.0.2 and earlier and prefer to never cache symmetric secrets
OAuth2 tokens can expire much sooner than the 90 days, 180 days, 1 year (default) of PATs
OAuth2 tokens support renewal that's very straight forward without leaving long-lived orphans around
OAuth2 is standards-based and has been embraced by other major Microsoft and non-Microsoft services alike
OAuth2 is popular enough that it's familiar to users and not too confusing to understand
OAuth2 does not impose a credential type, leaving an option to provide asymmetric / SSH-style auth down the road
OAuth2 has a well-understood threat model
Fewer authentication methods means a smaller attack surface, not to mention less code to maintain and a smaller service to operate; the smaller the code base/service, the easier to onboard new team members
Obviously, given you’re operating a service, you do have to consider backwards compatibility, but if you guys have some freedom to simplify / streamline authentication, I suggest doing so aggressively in the least esoteric, most future-embracing way possible.
@yacaovsnc , @AlexRukhlin , as we discussed via email (during course of Issue #85 ), there are numerous benefits to fully embracing OAuth2 for authentication in TEE 14.0.4+ instead of automatically creating and relying on a Personal Access Token (PAT):
Obviously, given you’re operating a service, you do have to consider backwards compatibility, but if you guys have some freedom to simplify / streamline authentication, I suggest doing so aggressively in the least esoteric, most future-embracing way possible.