wonderwall
![anyway here's wonderwall](https://i.imgur.com/NhRLEej.png)
Wonderwall is an application that implements an OpenID Connect (OIDC) relying party/client in a way that makes it
easy to plug into Kubernetes applications as a sidecar.
As such, this is OIDC as a sidecar, or OaaS, or to explain the joke:
Oasis - Wonderwall
Wonderwall functions as a reverse proxy that should be placed in front of your application; intercepting and proxying requests.
It provides endpoints to perform logins and logouts for end users, along with session management - so that your application does not have to.
Architecturally, Wonderwall is modeled after the backend-for-frontend (BFF) pattern as described in Best Current Practices - OAuth 2.0 for Browser-Based Apps, section 6.1.
Features
Wonderwall aims to be compliant with OAuth 2.1, and supports the following:
How it works
End-user authentication using Wonderwall is fairly straightforward:
- If the user does not have a valid local session with the sidecar, requests will be proxied to the upstream host as-is without modifications.
- To obtain a local session, the user must be redirected to the
/oauth2/login
endpoint, which will initiate the
OpenID Connect Authorization Code Flow.
- 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.
- All requests that are forwarded to the upstream host will now contain an
Authorization
header with the user's access_token
as a Bearer token, as long as the session is not expired or inactive.
- To log out, the user must be redirected to the
/oauth2/logout
endpoint.
Detailed documentation can be found in the documentation directory:
Quickstart
See docker-compose.example.yml for an example setup:
docker-compose -f docker-compose.example.yml up
This starts:
Try it out:
- Visit http://localhost:3000
- The response should be returned as-is from the upstream.
- The
authorization
header should not be set.
- 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.
- Visit http://localhost:3000/oauth2/logout
- The
authorization
header should no longer be set in the upstream response.
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>
Development
Requires Go 1.23
docker-compose up -d
make local