Skip to main content

Module auth

Module auth 

Source
Expand description

OAuth2 authentication: PKCE loopback flow (RFC 8252) with an RFC 8628 device-flow fallback, tokens in the OS keyring.

Multi-account: one OAuth client, one token per Google account. An auth handle is bound to one account’s store entry (the default account keeps the legacy naming byte-for-byte); named accounts log in independently.

Structs§

AuthConfigBuilder
DeviceAuthChallenge
Pending device authorization: show verification_url + user_code to the user, then poll with super::GoogleAuth::poll_device_code until done.
GoogleAuth
OAuth2 client with PKCE support
TokenStorage
Token storage with automatic refresh.

Functions§

login_scopes
[LOGIN_SCOPES], filtered to scopes the embedded index actually declares — requesting one no build can declare is a consent hang of its own.
scopes
Every scope the embedded index names, minus the ones Google will not show a user (see [APP_AUTH_SCOPES]), plus a curated floor for scopes no method declares. This is the superset a credential may hold — what grr auth login --all-scopes asks for, and what grr api describe counts against — but deliberately not what a login requests by default: see login_scopes for why the default is small. A token keeps whatever it was granted, so a build that widens this list needs one grr auth login to take effect.
scopes_for_service
Every scope one service’s methods declare for grr auth login --service. The index is the same source the command tree and grr api describe read, so the set matches exactly what that service can be asked to do — and stays far below the size at which Google’s consent screen stops submitting. None when the index has no such service.