wundergraph

Openid Connect built-in

WunderGraph comes with a built-in Openid Connect relying party implementation. That is, your WunderNode does not only persist & execute Queries as well as caching but can also be responsible for logging in your users, refreshing tokens, etc..

Additionally we offer templates to generate Clients that don't just fetch data but also know the OIDC flows to login a user and refresh their tokens.

Setup in minutes

If you want to build an app with user Login using GitHub, Google, LinkedIn or any other Openid Connect provider you can do so just by configuring an auth provider and a client. The client gets generated by our codegen to make the whole flow as easy as possible. Instead of figuring out the configuration, required dependencies, etc. you're able to setup an app using OIDC in just a few minutes.

PKCE & Refresh Tokens

If you're concerned about security in modern SPA's you've probably heard of PKCE. By default we're using PKCE & refresh Tokens to make your SPA as secure as possible as this is the flow that is currently proposed by security advisors.

Using Claims in GraphQL Queries

As you might have learned already, WunderGraph persists Queries by default. Combined with a built in Openid Connect implementation we're able to use claims within our Queries. Take a look at the following example to illustrate the idea:

query AllTasks($email: String! @fromClaim(name: "email")) {
queryTask(filter: {email: {eq: $email}}){
id
title
completed
}
}

This Query gets persisted so clients cannot see or change it, it stays on the server. This client contains a custom directive:

@fromClaim(name: "email")

With this directive we tell the WunderNode to never accept any value for the $email variable from the user. Instead the user MUST present a valid token from which we will extract the email claim.

This means we can build "insecure" backends and inject variables from claims. This makes backend development easier and the usability of those APIs more flexible.