Skip to content

Add SSO connection routing for org-scoped login and pc target re-auth#86

Open
austin-denoble wants to merge 9 commits intomainfrom
adenoble/sso-support
Open

Add SSO connection routing for org-scoped login and pc target re-auth#86
austin-denoble wants to merge 9 commits intomainfrom
adenoble/sso-support

Conversation

@austin-denoble
Copy link
Copy Markdown
Collaborator

@austin-denoble austin-denoble commented Apr 13, 2026

Problem

We currently do not support SSO in the CLI, and need to enable this for customers using this.

Solution

When authenticating into an organization that has SSO enforced, the CLI now passes the Auth0 connection name as a connection= parameter to the authorization endpoint, routing the browser directly to the org's identity provider rather than the generic login page.

Both pc login and pc auth login accept a new --org flag to scope the login to a specific organization. pc target already passes the org ID implicitly. In all cases the SSO connection is resolved by calling the dashboard organizations API with the user's existing token; the lookup is best-effort and non-fatal — if it fails the flow falls back to the
standard login page transparently.

Type of Change

  • Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Breaking change (fix or feature that would cause existing functionality to not work as expected)
  • This change requires a documentation update
  • Infrastructure change (CI configs, etc)
  • Non-code change (docs, etc)
  • None of the above: (explain here)

Test Plan


Note

Medium Risk
Touches core authentication and session-resume logic (including daemon/JSON mode) and adds a new dashboard API dependency for SSO lookup, which could affect login/retarget flows if misrouted or the lookup behaves unexpectedly.

Overview
Adds an --org flag to pc login and pc auth login to pin authentication to a specific organization and enable SSO routing.

Extends the OAuth login flow to optionally pass an Auth0 connection parameter, including best-effort lookup of an org’s enforced SSO connection via the dashboard organizations API; when SSO is enforced, login performs a second SSO-specific round (tracked in session state) so agents still get a pending URL then an authenticated result.

Updates pc target re-auth to resolve the SSO connection before oauth.Logout() and to pass it into GetAndSetAccessToken, and adjusts interactive login timeouts/contexts to avoid the root command timeout breaking slow browser auth.

Reviewed by Cursor Bugbot for commit 4a5b55a. Bugbot is set up for automated code reviews on this repo. Configure here.

  When authenticating into an organization that has SSO enforced, the CLI
  now passes the Auth0 connection name as a connection= parameter to the
  authorization endpoint, routing the browser directly to the org's
  identity provider rather than the generic login page.

  Both pc login and pc auth login accept a new --org flag to scope the
  login to a specific organization. pc target already passes the org ID
  implicitly. In all cases the SSO connection is resolved by calling the
  dashboard organizations API with the user's existing token; the lookup
  is best-effort and non-fatal — if it fails the flow falls back to the
  standard login page transparently.
Comment thread internal/pkg/utils/login/login.go Outdated
Comment thread internal/pkg/utils/login/login.go Outdated
Comment thread internal/pkg/utils/login/login.go
Comment thread internal/pkg/utils/login/login.go
Comment thread internal/pkg/utils/login/login.go
Comment thread internal/pkg/utils/login/login.go
Copy link
Copy Markdown

@cursor cursor bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Cursor Bugbot has reviewed your changes and found 1 potential issue.

Fix All in Cursor

❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.

Reviewed by Cursor Bugbot for commit 4a5b55a. Configure here.

CSRFState: csrfState,
AuthURL: authURL,
OrgId: orgId,
CreatedAt: time.Now(),
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pending session resumed despite org mismatch with --org

Medium Severity

When --org is specified but a pending session exists from a prior login without --org (i.e., sess.OrgId is nil), the org mismatch guard at line 245 (orgId != nil && sess.OrgId != nil && ...) short-circuits to false because sess.OrgId is nil. This causes resumeSession to be called, completing the old session and potentially yielding a token for the user's default org instead of the org they explicitly requested via --org. Before this PR, orgId was always nil in this call path, so the check was irrelevant; now that opts.OrgId is passed, the condition needs to also treat a nil sess.OrgId as a mismatch when orgId is non-nil.

Additional Locations (1)
Fix in Cursor Fix in Web

Reviewed by Cursor Bugbot for commit 4a5b55a. Configure here.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant