CliOAuth
The CLI's side of bldr login: the OAuth token and revocation endpoints, over gRPC rather than form-encoded HTTP so the CLI reaches them on the same origin and transport as every other call.
The CLI's side of bldr login: the OAuth token and revocation endpoints,
over gRPC rather than form-encoded HTTP so the CLI reaches them on the same
origin and transport as every other call.
No authorization header here. Token is authenticated by the code and its
PKCE verifier, Revoke by possession of the token it revokes.
Service bldr.service.v1.CliOAuth, 2 rpcs.
Token(TokenRequest) -> TokenResponse
Exchange an authorization code for an access token (RFC 6749 §4.1.3).
Failures are INVALID_ARGUMENT or FAILED_PRECONDITION with the OAuth error
code (invalid_grant, invalid_request, …) leading the message. A code
presented a second time also revokes the token it was first exchanged for
(RFC 6749 §4.1.2).
Request: TokenRequest
RFC 6749 §4.1.3, field for field.
message TokenRequest {
optional string grant_type = 1;
optional string code = 2;
optional string redirect_uri = 3;
optional string client_id = 4;
optional string code_verifier = 5;
}| Field | |
|---|---|
grant_type | "authorization_code" |
code | |
redirect_uri | exactly as sent to the console |
client_id | "bldr-cli" |
code_verifier |
Response: TokenResponse
message TokenResponse {
optional string access_token = 1;
optional string token_type = 2;
optional CliAuthorization authorization = 3;
}| Field | |
|---|---|
access_token | Opaque, bldr_cli_-prefixed. Send as authorization: Bearer <token>. |
token_type | "Bearer" |
authorization | What was granted, so the CLI can say who it now is without a second call. |
Revoke(RevokeTokenRequest) -> RevokeTokenResponse
Revoke the presented token (RFC 7009). Revoking an unknown or already
revoked token succeeds, so bldr logout is safe to repeat.
Request: RevokeTokenRequest
message RevokeTokenRequest {
optional string token = 1;
}Response: RevokeTokenResponse
message RevokeTokenResponse {
// no fields
}