Cookie-Based Authentication is the best possible authentication flow to be used with a web-based application. The WunderGraph Server acts as a Token Handler in this case. The whole flow is handled server-side, on the WunderGraph server, meaning that an auth code is obtained via the browser but exchanged via the secure back-channel (server-to-server).
Once the Authentication flow is complete, a secure encrypted cookie is set, which keeps the user logged in.
WunderGraph relies on OpenID Connect (OIDC) Identity Providers to be able to authenticate users. Possible providers could be:
- any other OIDC compatible provider
Authorized Redirect URIs
The WunderGraph Authentication workflow looks like this. First, the web Application starts the login flow and redirects the user to the WunderGraph Server (WunderNode). The WunderNode will then redirect the user to the auth provider. Once the login flow is successful, the user will be redirected back to the web application.
To make this flow as secure as possible, we have to configure a whitelist of authorized redirect URIs. These URIs are the only allowed targets to redirect to after a successful authentication flow. You have to explicitly allow all URIs.
Find below an annotated version of
Important Notes for Production Use
When deploying to production, you might be running into the following issue:
This is because cookie-based authentication relies on secrets for the cookie encryption and the CSRF token. During development, we use a static (insecure) secret so that you don't have to configure anything. In production, you have to provide your own secrets for security reasons.
The following example configuration shows you how to set this up properly. Make sure that all values have the correct length and are secure random strings.