Terraform login makes hosted-service credentials a CLI operation

Connecting a local infrastructure tool to a hosted service requires a credential to cross the boundary between browser and terminal. Terraform 0.12.21 makes that step an explicit CLI operation with terraform login. The useful change is a supported process for obtaining and storing a host-specific token, including a fallback for services that create tokens through their web interface.

The February 19 release also adds terraform logout. These commands address different parts of credential handling. Login obtains credentials and records them for subsequent commands. Logout removes the locally stored credential. The distinction between deleting a local copy and revoking the server-side token remains important throughout the workflow.

I like Terraform's ability to give a consistent interface to different infrastructure services. Host-aware authentication extends that consistency to the work surrounding a configuration. It also creates an implementation that users can inspect instead of relying on separate instructions for editing a credentials file.

The host determines the login process

The versioned command documentation gives a short invocation. Without a hostname, Terraform selects app.terraform.io. A hostname argument selects another service host.

terraform login
terraform login terraform.example.com

The second command illustrates the syntax for a supporting host. It does not imply that an arbitrary server can accept Terraform credentials. The server must expose services Terraform understands, and discovery determines which login route is available.

The 0.12.21 implementation first discovers the host and looks for the login.v1 OAuth configuration. If that configuration is unavailable, it looks for the tfe.v2 service and can use the UI-based token creation process. This explains the release note's specific mention of support for UI-generated tokens. Browser participation does not require every server to implement the same OAuth endpoint arrangement.

An unsupported host produces a diagnostic. Terraform also rejects login when command input is disabled. That check makes the interactive nature of the operation a property of the implementation, rather than merely a suggestion in the documentation. Unattended execution needs credentials configured through the CLI configuration instead.

OAuth without a client secret

The versioned server-side login protocol describes the OAuth route for third-party service implementers. Service discovery supplies a client identifier and endpoint information. Terraform supports the authorization-code grant and opens a temporary loopback HTTP listener to receive the authorization response.

A server can specify an inclusive range of callback ports. That accommodates OAuth implementations which require registered redirect addresses, while giving the CLI alternatives if a port is already occupied. The documentation recommends allowing several possible ports to reduce the chance that local processes prevent login.

Terraform is a public OAuth client. Installing its executable on a user's machine means it cannot protect a shared client secret. The protocol documentation explicitly warns servers against treating the client identifier as proof that the request came from Terraform. It also describes Proof Key for Code Exchange, which protects the code exchange against interception of the local redirect.

This version does not support refresh tokens or token expiration handling. A time-limited token eventually produces authorization failures, after which the user can run login again. That limitation affects service design as well as terminal behavior. Issuing a short-lived token does not create an automatic renewal process in this CLI.

Storage remains an explicit decision

By default, login writes the token as plain text in credentials.tfrc.json. Before doing so, it explains the destination and gives the user a chance to cancel. The documented alternative is a credentials helper that stores and retrieves credentials through another system.

That choice keeps acquisition separate from storage. A service can supply an appropriate token while a helper determines where the local credential lives. The login command therefore does not require every organization to accept the same storage arrangement merely to use the same hosted Terraform service.

The implementation also detects credentials manually configured in another CLI configuration file. It refuses to replace them through login and explains that the existing credential block needs attention. This avoids an ambiguous situation in which a new token is saved but a separate configuration continues to supply the credential actually used.

Local logout has a limited scope

The logout implementation and embedded help state that removing the stored token does not destroy it on the remote server. It remains valid until manually revoked. Logout can also remove credentials through a configured helper, while manually configured credential blocks require manual removal.

I consider that distinction necessary for understanding the command. Logging out of one workstation changes what that workstation can retrieve locally. It does not establish that every copy of the token has lost authority. Server-side revocation is a separate action with a different effect.

The release makes the ordinary interactive path shorter without hiding its components. Host discovery selects a supported acquisition process, the command records the resulting token, and later commands can retrieve it through the configured credential source. For an engineer operating against multiple service hosts, the hostname remains the unit that connects those steps.