feat(auth): add OIDC auth-code + PKCE login helper#534
Draft
aparajon wants to merge 1 commit into
Draft
Conversation
There was a problem hiding this comment.
Pull request overview
Adds a standalone CLI-side OIDC login helper that performs the OAuth2 authorization-code + PKCE flow (discovery, loopback callback server, browser open, state validation, code exchange) plus an in-process fake OIDC provider test harness to exercise the flow end-to-end. This lays the groundwork for a future login command without changing current runtime behavior.
Changes:
- Introduces
client.Loginand related config/result types to run OIDC auth-code + PKCE via a loopback redirect. - Adds unit tests with an in-process fake OIDC provider that validates the PKCE S256 round-trip and negative cases.
- Promotes
golang.org/x/oauth2to a direct dependency.
Reviewed changes
Copilot reviewed 3 out of 3 changed files in this pull request and generated 3 comments.
| File | Description |
|---|---|
| pkg/cmd/client/login.go | New OIDC auth-code + PKCE login helper with loopback callback server and token exchange. |
| pkg/cmd/client/login_test.go | End-to-end unit tests using a fake in-process OIDC provider to validate the flow and error handling. |
| go.mod | Adds golang.org/x/oauth2 as a direct dependency. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
Add a Login helper that runs the OAuth2 authorization-code flow with PKCE for a public client: discover the provider's endpoints, start a loopback callback server, open the browser at the authorization URL (S256 challenge + state), receive the code on the loopback redirect (verifying state), and exchange it (with the PKCE verifier) for tokens. The helper is standalone and browser-agnostic — the caller supplies the browser opener — so the interactive login command can wire it later. The whole flow is bounded by the caller's context and the loopback server is always shut down before returning. Promotes golang.org/x/oauth2 to a direct dependency. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
a888cc0 to
09cc360
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Why this matters
A CLI needs a way to obtain a token interactively without users hand-copying credentials. This adds the OIDC login engine — the authorization-code + PKCE flow — that an interactive
logincommand will drive. It lands as a standalone helper; nothing calls it yet, so there is no behavior change.What it does
client.Login, which runs the OAuth2 authorization-code flow with PKCE for a public client: discovers the provider's endpoints, starts a loopback callback server, opens the browser at the authorization URL (S256 challenge + a random state), receives the code on the loopback redirect (verifying the state matches), and exchanges it — with the PKCE verifier — for tokens.golang.org/x/oauth2to a direct dependency.How it fits
Part of the optional client-side authentication workstream. This is the login engine; a later change wires the interactive
login/logoutcommands and the on-disk token cache around it, and adds the end-to-end test against a real OIDC provider.