Based on feedback from the API call, I've some changes to the API:

[birkanekinci06]

          Based on feedback from the API call, I've some changes to the API:

export interface Session {
	id: string;
	accessToken: string;
	displayName: string;
}

export interface AuthenticationProvider {
	readonly id: string;
	readonly displayName: string;
	readonly onDidChangeSessions: Event<void>;

	/**
	 * Returns an array of current sessions.
	 */
	getSessions(): Promise<ReadonlyArray<Session>>;

	/**
	 * Prompts a user to login.
	 */
	login(): Promise<Session>;
	logout(sessionId: string): Promise<void>;
}

export namespace authentication {
	export function registerAuthenticationProvider(provider: AuthenticationProvider): Disposable;

	/**
	 * Fires with the provider id that was registered or unregistered.
	 */
	export const onDidRegisterAuthenticationProvider: Event<string>;
	export const onDidUnregisterAuthenticationProvider: Event<string>;

	/**
	 * Fires with the provider id that changed sessions.
	 */
	export const onDidChangeSessions: Event<string>;
	export function login(providerId: string): Promise<Session>;
	export function logout(providerId: string, accountId: string): Promise<void>;
	export function getSessions(providerId: string): Promise<ReadonlyArray<Session> | undefined>;
}

Account has been replaced with Session. There are now events register and unregister events that can be listened to, as well as more explicit calls that extensions can make to perform an action with a specific provider, instead of searching through an array of providers.

We had discussed combining login and getSessions, but after thinking about it more, I think these should remain separate. When consuming this API with settings sync, I want to be able to check if there are existing sessions without popping up a browser for sign in. However, with the change to expose getSessions instead of the authenticationProviders array, it should be easy to add a consent notification that indicates an extension is trying to access token information from another extension.

We also discussed moving the authentication provider display name out to a contribution point - I think this is reasonable, I just haven't done this yet.

One open question is about additional information that might be needed for login and on the session itself. For OAuth, the clientId and scopes are typically passed as parameters. Should these be added as parameters to login? Or should login take an unstructured, optional parameter bag that the provider would determine? Likewise, for sessions themselves, for OAuth, consumers would likely want to know what scopes a given session has to see if it can be used.

Originally posted by @RMacfarlane in microsoft/vscode#88309 (comment)