Sign in from a command-line interface (CLI) through the system browser.

Command-line tools need user authorization too, but they often cannot safely collect passwords or display a full sign-in interface. A common design is to let the command-line client start OAuth while the user completes authentication and consent in the system browser.

The command-line client creates the authorization request and opens the browser. The user signs in at the authorization server, not inside the command-line tool. The browser then returns an authorization code to a local callback or another approved redirect mechanism. The client exchanges that code for tokens using Proof Key for Code Exchange (PKCE).

This is useful because the client never needs to handle the user’s primary password, and the authorization server can use the same sign-in and multifactor controls it uses for normal web applications. The user can also see which permissions the command-line client is requesting.

The client still has to protect the returned code and tokens, validate state and redirect behavior, and store long-lived credentials carefully. A command-line interface changes the user experience, but it does not remove the normal OAuth security requirements.