Skip to content

Authentication Provider API #88309

@RMacfarlane

Description

@RMacfarlane

Problem

There are currently some extensions that attempt to provide authentication abilities that can be reused by other extensions. (An example being the Azure Account extension). Now that we've begun working on login for settings sync, it's worth revisiting if authentication should be a first-class concept in VS Code. By exposing an API to contribute an authentication flow

  • the core of VSCode can potentially leverage authentication
  • other extensions can leverage authentication
  • UI for account management could be centralized

Proposal

I propose introducing a concept of an "AuthenticationProvider". Such a provider implements methods for logging in and logging out of a specified account, and exposes a list of accounts that are currently available with an event listener for changes to these. This abstracts away refreshing tokens from consumers - the AuthenticationProvider extension can manage refreshing in the background and fire an event when the accessToken has been changed.

export interface Account {
	readonly id: string;
	readonly accessToken: string;
	readonly displayName: string;
}

export interface AuthenticationProvider {
	readonly id: string; // perhaps "type"? Would be something like "GitHub", "MSA", etc.
	readonly displayName: string;

	accounts: ReadonlyArray<Account>;
	onDidChangeAccounts: Event<ReadonlyArray<Account>>;

	login(): Promise<Account>;
	logout(accountId: string): Promise<void>;
}

export namespace authentication {
	export function registerAuthenticationProvider(provider: AuthenticationProvider): Disposable;
	export const authenticationProviders: ReadonlyArray<AuthenticationProvider>;
}

Consumers would need to know the id of the provider they're looking for. For example, the settings sync code would look for an "MSA" provider since this is what the setting sync backend currently needs.

Since the authentication provider extension would be activated in each VS Code window, the extension would be responsible for synchronizing state across instances. By default, such extensions would have ["ui", "workspace"] extensionKind, so that they can store and read credentials on the local machine in both the desktop and web case.

Metadata

Metadata

Assignees

Type

No type

Projects

No projects

Milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions