Wonderwall

Wonderwall is a reverse proxy that implements an OpenID Connect (OIDC) relying party (or client), primarily for use as a Kubernetes sidecar.

As such, this is OIDC as a sidecar, or OaaS, or to explain the joke:

Oasis - Wonderwall

Features

Wonderwall aims to be compliant with OAuth 2.1, and supports the following:

• OpenID Connect Authorization Code Flow with mandatory use of PKCE, state and nonce
• Client authentication using client assertions (private_key_jwt) (RFC 7523, Section 2.2)
• OpenID Connect RP-Initiated Logout
• OpenID Connect Front-Channel Logout
• OAuth 2.0 Pushed Authorization Requests (RFC 9126)
• Sessions stored in Redis, encrypted with XChaCha20-Poly1305.
• Two deployment modes:
  • Standalone mode (default) for zero-trust based setups where each application has its own perimeter and client
  • Single sign-on (SSO) mode for shared authentication across multiple applications on a common domain

Wonderwall fits in the backend-for-frontend (BFF) pattern as described in Best Current Practices - OAuth 2.0 for Browser-Based Apps, section 6.1.

For further details, see the documentation directory:

• Architecture
• Configuration
• Endpoints
• Usage
• Sessions

How it works

Wonderwall abstracts away the complexities of authentication and session management from your application, making end-user authentication fairly straightforward.

Unauthenticated requests

If the user does not have a valid session, requests will be proxied to the upstream host as-is without modifications.

Log in a user

To establish a session, redirect the user to the /oauth2/login endpoint. This initiates the OpenID Connect Authorization Code Flow.

Authenticated requests

If the user successfully completed the login flow, the sidecar creates and stores a session. A corresponding session cookie is created and set before finally redirecting user agent to the application.

As long as the session is valid, the user's access token is attached for all requests to the upstream:

GET /some/path HTTP/1.1
Host: 127.0.0.1:8080
Authorization: Bearer <access_token>

Log out a user

To log out, redirect the user to the /oauth2/logout endpoint. This clears the session and redirects the user to the identity provider for single-logout.

Quick start

See docker-compose.example.yml for an example setup:

docker-compose -f docker-compose.example.yml up

Unauthenticated request

Visit http://localhost:3000.

The response should be returned as-is from the upstream. The authorization header should not be set.

Log in

Visit http://localhost:3000/oauth2/login.

The authorization header should now be set in the upstream response. The response should also include the decoded JWT from said header.

Log out

Visit http://localhost:3000/oauth2/logout.

The authorization header should no longer be set in the upstream response.

Development

Requires Go 1.24.

Start up dependencies:

docker-compose up -d

Start Wonderwall:

make local

Docker Images

Wonderwall is available on both GitHub Container Registry and Google Artifact Registry:

• ghcr.io/nais/wonderwall
• europe-north1-docker.pkg.dev/nais-io/nais/images/wonderwall

For available tags, see the versions overview on GitHub.

Verifying the Wonderwall image and its contents

The image is signed "keylessly" using Sigstore cosign. To verify its authenticity run

cosign verify europe-north1-docker.pkg.dev/nais-io/nais/images/wonderwall@sha25:<shasum> \
--certificate-oidc-issuer "https://token.actions.githubusercontent.com" \
--certificate-identity "https://github.com/nais/wonderwall/.github/workflows/deploy.yml@refs/heads/master"

The images are also attested with SBOMs in the CycloneDX format. You can verify these by running

cosign verify-attestation --type cyclonedx \
--certificate-identity "https://github.com/nais/wonderwall/.github/workflows/deploy.yml@refs/heads/master" \
--certificate-oidc-issuer "https://token.actions.githubusercontent.com" \
europe-north1-docker.pkg.dev/nais-io/nais/images/wonderwall@sha25:<shasum>