Absinthe authentication with JWT tokens

The following may not be applicable because I don’t know all the context for your use case… but one thing that’s worth remembering about signed JWTs is that they are self-validating. If you trust the signer of the token, then you can trust the token. This means that your Absinthe API doesn’t need to generate tokens at all (or keep them in sessions). It can simply accept a bearer token in the Authorization header of all requests and then you crack that open when you build your context and add a user, scopes, etc.

This is essentially what I’m doing for my project. I don’t know if there are hidden dangers here, but I like this because it means that the front end can generate and sign tokens at will and the back-end can validate those tokens, and nobody needs a session anywhere.

httpOnly cookies cannot be accessed from Javascript, therefore you React app will not be able to use them.

I never coded in React, but if possible store the token returned from the backend in the some React internal state.

I work in API security and never heard this assertions that JWT tokens are self-validating. Do you mind to elaborate more on this?

If you sign a JWT with a private key, and include the corresponding public key inside the JWT in the iss field, then you know that the JWT was signed by whoever claims to have signed it (assuming you’re validating the signature). You can essentially use the issuer field like an API key - if you trust the issuer (e.g. your web UI) then you can simply accept the contents at face value and assume that the user (sub) in the JWT is correct. You can use aud to validate that the token is going to a specific URL and you can use the expiration field to make time-limited bearer tokens, etc.

This is why I said I don’t know if what I’m suggesting is appropriate for your use case - some scenarios don’t allow for this kind of security pattern.

httpOnly cookies cannot be accessed from javascript, therefore you React app will not be able to use them

You can configure Apollo to include HttpOnly cookies when making HTTP requests. Where the option is passed to the browser API the cookies don’t need read by Javascript.

Now I know waht you are talking about This is called signing the JWT with the RS256 asymmetric signing algorithm.

Are you saying that the JWT token will be signed with a private key stored in the browser and then the backend will validate it by using it’s public key? Or do you mean by Web UI the backend responsible to deliver it to the browser?

The JWT is signed at the web backend and stored in the client side (Usually as a cookie) as an opaque data. It is also tamper proof.
Two different server-side applications can share the same key to form a trusted domain, so one application can trust the JWT from another application. With Guardian it is the sharing of the Guardian key.

Sorry, auth tokens are generated on the front end? How does that work?

I was (perhaps incorrectly so) assuming that there were two Phoenix apps - a “front-end/UI” app and the Absinthe app, which is the GraphQL API. The flow I imagined was something like:

Phoenix/LiveView -> OAuth redir -> Phoenix/LiveView -> JWT -> Absinthe

This is obviously not a one-size-fits-all scenario and probably has more steps in it than most people need. But the general idea was that the UI web app would sign JWTs with its key which could then be verified by the Absinthe app via bearer token auth.

Thanks for the the explanation, and I already understood this flow, but by the way it was phrased I was left with the impression that would be the web app on the browser signing them.