Skip to content

E2E: Use regular MockAuth client as upstream for proxy client to validate full proxy flow #135

Description

@rowan-stein

User request
Create an end-to-end (E2E) test that uses a regular MockAuth client as the upstream for a proxy MockAuth client. This should be the easiest way to verify the proxy flow.

Spec (summary by research)

  • Topology (single instance)
    • Upstream regular client A: confidential, token auth method client_secret_post, PKCE not required, issues standard MockAuth tokens (optionally id_token). Register B’s callback URI.
    • Proxy client B: points to A’s authorize/token endpoints; providerType=oidc; providerPkceEnabled=false; upstreamTokenEndpointAuthMethod=client_secret_post; app redirect URI to local test page.
  • Happy path
    • /authorize (B) → PROXY_REDIRECT_OUT with provider params (no PKCE)
    • Upstream authorize (A) via MockAuth login → callback to B
    • Callback token exchange stores provider tokens (access_token, id_token if issued)
    • Proxy code issued → App /token (authorization_code) returns stored provider tokens; assert upstreamCall=false in TOKEN_AUTHCODE_COMPLETED
  • Optional refresh
    • If A issues refresh_token: /token (refresh_token) calls upstream; else assert invalid_request (no refresh_token)
  • Negative cases
    • Expired/used proxy code → invalid_grant; audit reflects error
    • Wrong upstream secret → PROXY_CALLBACK_ERROR with provider invalid_client; restore for happy path
  • Assertions & logs
    • Verify audit events sequence: AUTHORIZE_RECEIVED, PROXY_REDIRECT_OUT, PROXY_CALLBACK_SUCCESS, PROXY_CODE_ISSUED, TOKEN_AUTHCODE_RECEIVED/COMPLETED (upstreamCall=false)
    • Validate token fields and id_token passthrough
    • Ensure no upstream call occurs on authorization_code exchange
  • Implementation
    • Add Playwright spec: tests/e2e/proxy-mockauth-upstream.spec.ts
    • Seed via server actions/endpoints and admin UI (no direct DB)
    • Deterministic client names; teardown removes created clients
    • CI-friendly; no Prisma migrations

Acceptance criteria

  • E2E passes locally and in CI; confirms proxy authorization code exchange returns stored provider tokens with upstreamCall=false and exercises audit logs.
  • Negative cases pass; optional refresh covered if configured.

Activity

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

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions