Summary
After a successful SSO login, oauth2login() in cmd/login.go unconditionally logs both the OAuth access token and refresh token to stderr:
// cmd/login.go, lines 296-297
log.Printf("Token: %s\n", tokenString)
log.Printf("Refresh Token: %s\n", refreshToken)
This is a critical credential leak. The refresh token is long-lived and can be used to mint new access tokens. These logs can end up in:
- Terminal scrollback / shell history
- CI/CD pipeline logs
- Support bundles or shared debug output
- Shell capture tools (e.g.
script, tee)
A user only needs to run:
microcks login <server> --sso
and the CLI exposes the full session credentials after authentication.
Additional Leaks Found
| Leak |
Location |
Severity |
Content |
| Access token |
cmd/login.go:296 |
Critical |
Full JWT access token |
| Refresh token |
cmd/login.go:297 |
Critical |
Long-lived refresh token |
| Callback URL with auth code |
cmd/login.go:222 |
High |
OAuth authorization code via log.Printf("Callback: %s\n", r.URL) |
The callback URL log at line 222 also leaks the OAuth authorization code, which (though short-lived) can be exchanged for tokens if intercepted before the CLI completes the exchange.
Why This Is Critical
The project already stores tokens securely in a protected config file (~/.microcks/microcks.yaml), but these log lines bypass that protection entirely by printing secrets directly to the terminal. This logging is:
- Not gated behind
--verbose or any debug flag
- Always active on every SSO login
- Exposing both immediate access (access token) and long-term session hijack capability (refresh token)
Suggested Fix
- Remove the two
log.Printf calls at lines 296-297 that print the access and refresh tokens
- Remove or redact the callback URL log at line 222, or strip query parameters (which contain the OAuth
code)
- Audit any verbose/debug HTTP dump paths to ensure
Authorization, access_token, refresh_token, and id_token values are redacted
- Consider gating all OAuth-related debug logging behind an explicit
--verbose flag
Reproduction
microcks login http://localhost:8080 --sso
# After browser-based authentication completes, observe stderr output containing:
# Token: eyJhbGciOi...
# Refresh Token: eyJhbGciOi...
Environment
- microcks-cli: current main branch
- File:
cmd/login.go
- Lines: 222, 296-297
Summary
After a successful SSO login,
oauth2login()incmd/login.gounconditionally logs both the OAuth access token and refresh token to stderr:This is a critical credential leak. The refresh token is long-lived and can be used to mint new access tokens. These logs can end up in:
script,tee)A user only needs to run:
and the CLI exposes the full session credentials after authentication.
Additional Leaks Found
cmd/login.go:296cmd/login.go:297cmd/login.go:222log.Printf("Callback: %s\n", r.URL)The callback URL log at line 222 also leaks the OAuth authorization code, which (though short-lived) can be exchanged for tokens if intercepted before the CLI completes the exchange.
Why This Is Critical
The project already stores tokens securely in a protected config file (
~/.microcks/microcks.yaml), but these log lines bypass that protection entirely by printing secrets directly to the terminal. This logging is:--verboseor any debug flagSuggested Fix
log.Printfcalls at lines 296-297 that print the access and refresh tokenscode)Authorization,access_token,refresh_token, andid_tokenvalues are redacted--verboseflagReproduction
Environment
cmd/login.go