Authentication (JWT / CSRF)

[gotexis]

I believe authentication is one of the most common use cases,

yet I am having a hard time finding an out-of-the-box solution for authenticating the user with a React/Vue client (which will use JWT I guess).

Where can I find a minimal example?

[TitanFighter]

Just in case if you use Django: https://github.com/flavors/django-graphql-jwt

[Diggitysc]

I am running into this issue as well. (current stack is Django-graphene as graphql backend with apollo-client/react on the front end)

https://github.com/flavors/django-graphql-jwt provides a method to generate a jwt token (which I have working) however I haven't seen a good solution for storing the jwt in a cookie in apollo once the token has been generated. (https://www.rdegges.com/2018/please-stop-using-local-storage/)

I am hunting through making a working to this solution now, but a general use cases would be useful. I will provide updates if I am able to find solutions though I admit this may not be the best place for it as graphql-python is covering backend only.

update/sidenote: encryption for user/password from client-backend should be handled via SSL certs (HTTPS)

[gotexis]

@TitanFighter thanks, i have taken a look at the flavor project, i think it is helpful but need some more time to adapt. Will provide my experience once I have progress.

I also am aware of storing plan text token, but it is now only my secondary concern given they can be short lived (5min default).

However this would mean a strategy to regularly update token need to be implemented.

My biggest concern right now is actually how to implement Oauth and jwt together...

@Diggitysc Let's team up on this cause I feel like we are doing the same thing

Update take a look at
Apollo-auto-refreshing-jwt https://github.com/newsiberian/apollo-link-token-refresh

[Diggitysc]

@gotexis Sounds great! I will not be using Oauth but I think the configuration on the react side will be the same (cookie containing jwt). I have a feeling it may just be a lack of understanding on my part regarding the interaction between the front-end/backend, but I will come back with something once I have it.

As a side note I am appalled by the huge number of demos that give examples with local storage without providing an alternative solution that utilizes something secure (on the react end)

Further reading on the issue itself and advantages of cookies vs local storage: https://stormpath.com/blog/where-to-store-your-jwts-cookies-vs-html5-web-storage

TLDR of article above, storing JWT in local storage creates a large surface vulnerability to XSS (all javascript on local domain has access to local/session storage, if you have a js dependency that is compromised, which has happened multiple times historically, all data stored in JWT is exposed/captured). JWT in cookie is still vulnerable to CSRF exploits but most frameworks have CSRF protection (which is annoying to set up with CORS but is secure).

[Diggitysc]

At this stage with a lot of looking around I am starting to agree with the following two articles:

http://cryto.net/%7Ejoepie91/blog/2016/06/13/stop-using-jwt-for-sessions/
http://cryto.net/%7Ejoepie91/blog/2016/06/19/stop-using-jwt-for-sessions-part-2-why-your-solution-doesnt-work/

I am not going to go as far as the author and say that JWT is not worthwhile, simply that individuals should be aware of use cases for JWT and the risks involved, particularly for login/session management.

Use cases

I believe the best use case for JWT would be a microservice where a web browser and extraneous javascript code is not involved. This mitigates the risk of XSS issues.

For JWT with a web browser (and storage in local ), there needs to be a large amount of control over javascript/the machine that is executing the code to avoid XSS if there is any sensitive information contained in the web application. This seems particularly unlikely in the current react eco-system.

I do not currently see the advantages of JWT in Cookies over cookie session management. (may again be due to lack of research) However I think technologically I may be stuck with combining the two due to current limitations.

I will keep digging

[gotexis]

As I recall from reading one article, the main problem of criticism of JWT is the lack of a suitable alternative...

[Diggitysc]

It looks like https://github.com/flavors/django-graphql-jwt solved the authentication/JWT cookie problem with their latest update.

To implement: follow settings recommendations here: https://django-graphql-jwt.domake.io/en/stable/quickstart.html#installation

However also add a revoke_token mutation, listed in schema here: https://django-graphql-jwt.domake.io/en/stable/refresh_token.html

Then in urls.py add:

`from graphql_jwt.decorators import jwt_cookie`
 
urlpatterns = [
    path('graphql/', jwt_cookie(GraphQLView.as_view(graphiql=True))),
]

Then copy the resolve_me query courtsey of https://www.howtographql.com/graphql-python/4-authentication

(in query)

me = graphene.Field(UserType)

def resolve_me(self, info):
       user = info.context.user
       if user.is_anonymous:
           raise Exception('Not logged in!')

       return user

What does this do?
The jwt_cookie decorator assigns a JWT cookie AND logs the relevant user requesting the token in. Pretty handy!

So if you execute a tokenAuth mutation with user/password, then run the "me" query, you should get back the relevant user to the tokenAuth request. Additionally if you check your browser cookies, you will notice a big JWT cookie in place.

Why do I need this?

The following video is extremely informative (time stamp to relevant information but for angularjs)
https://www.youtube.com/watch?v=WzfJgCOMIsU&feature=youtu.be&t=24m20s

TLDW:

• XSS insecure
• Cookies are secure (with HttpOnly and Secure flags w/ CSRF protection, feel free to keep off for dev/test if not exposed to the web)
• Javascript cannot access cookies (when HttpOnly is set to true which prevents XSS), so how do we get relevant data?

Solution with jwt_cookie decorator:
The browser stores a cookie with the relevant JWT data required. The client-in-browser can then access relevant endpoints that expose the sensitive data (username etc) without exposing the JWT or other authentication data to XSS attacks via javascript (javascript cannot access cookies). Django has CSRF protection (CSRF in separate token that is not HttpOnly so it is readable) in place to provide cookie security (be sure to use settings carefully to avoid security/implementation problems).

As a last bit, be sure that a logout includes a call to revoke_token.

On the react side, if you are using apollo just set credentials to 'same-origin':
https://www.apollographql.com/docs/react/recipes/authentication.html

For legacy discussion (from which I plucked information) see the relevant issues page here: flavors/django-graphql-jwt#75

Update on current issues:

Read apollo/django implementation on comment below

Thanks to everyone that contributes to graphql-python and all the django-graphql-jwt contributors here: https://django-graphql-jwt.domake.io/en/stable/contributors.html

[gotexis]

@Diggitysc

Haha, actually I just saw your GraphQL howto repo and couldn't believe what I've seen. You are becoming the champion of GraphQL sir :)

OK so both you and @mongkok author of GraphQL_JWT recommended me to use cookies instead of LocalStorage.... Hmmmm

flavors/django-graphql-jwt#85

OK ket's do it then :)

Too bad I am at exactly where you are at, just with Vue, not React, but it's basically the same.

CSRF Token not set.

What I have tried:

• Use Django-CORS-Header
  -- ALLOW_ALL_ORIGIN: True
• SESSION_COOKIE_SAMESITE: None
• CSRF_COOKIE_SAMESITE = 'None'
• SESSION_COOKIE_HTTPONLY = False
• CSRF_COOKIE_HTTPONLY = False
• disable Clickjacking.Middleware
• CSRF_TRUSTED_ORIGINS = ["10.0.75.1:8080", "10.0.75.1"]
• adding ensure_csrf decorator to wrap GraphQLView

Nothing worked.... OMFG

I have even checked the dispatch function of Graphene's Views, and did saw they implement a ensure_csrf on one of the functions.

So exactly as you said

CSRF cookie on request as that halts the post process altogether

And that means the introspection query cannot proceed, so nothing works ....

Checking:

• Add a breakpoint to CSRF middleware to see if the CSRF has been set on header: checked, it seems that cookies can successfully be included in responses, can even be set on the client browser, but there is no way to read it from my SPA, because SPA cannot access cross-site cookies...

• Just make a GET call to obtain the CSRF_TOKEN before initializing the Vue App... Some would claim this would defeat the purpose of CSRF protection, but currently I see this is the only effective way, but then maybe it's better for CSRF to be disabled for good.

adamchainz/django-cors-headers#162

p.s. Plz help me do Oauth buddy :)

[Diggitysc]

Update on Apollo/Django implementation:

If you are ejecting (react-create-app) and running your javascript code from django you shouldn't need the below (as csrf tokens should be assigned/accessible via the same port). I haven't tested that aspect out, but if someone does please let me know if you ran into any trouble or not.

For the rest of us, often times django-graphene is running from some port (typically 8000) for dev purposes while a javascript dev environment is running on some other port (typically 3000). This creates a problem where when CSRF protection is enabled, a CSRF cookie is never set for the javascript environment to give a proper security return.

This means you need to expose a CSRF cookie so that it can then be ingested and set on the javascript front end so it can make a call to the /graphql/ end point to get a JWT token cookie (via django-graphql-jwt) for further XSS/CSRF safe authentication (quite the sentence).

Special thanks to this article here https://fractalideas.com/blog/making-react-and-django-play-well-together-single-page-app-model/ on how to expose CSRF cookies.

From the article:

INSTALLED_APPS = [
    ...,
    'corsheaders',
    ...
]

MIDDLEWARE = [
    ...,
    # just after django.middleware.security.SecurityMiddleware
    'corsheaders.middleware.CorsMiddleware',
    ...,
]

CORS_ALLOW_CREDENTIALS = True
CORS_ORIGIN_WHITELIST = ['<host>:3000']
CSRF_TRUSTED_ORIGINS = ['<host>:3000']

For debugging it is helpful to set CORS_EXPOSE_HEADERS (to make it viewable). If you really want to dig deep on the django side of things you will want to put pdb breaks in /django/middleware/csrf.py (in env lib environment)

Now that CORS is set up, set up a url endpoint that is passing a CSRF token. As mentioned in the original article, this is fine as "the browser’s same-origin policy prevents an attacker from getting access to the token with a cross-origin request"

In your baseline apps views.py:

from django.http import JsonResponse
from django.middleware.csrf import get_token

def csrf(request):
    return JsonResponse({'csrfToken': get_token(request)})

and in urls.py add:

from . import views

urlpatterns = [
    ...
    path('csrf/', views.csrf),
    ...
]

If you go to your app/csrf, you should get a fresh csrf request token

OK now to Apollo

You are going to need to do a couple of things

1. Set a 'csrftoken' cookie
2. 'X-CSRFToken' header response
3. Do the above asynchronously to avoid csrf refresh problems (huge pain to figure out)

I am using boost as I like the condensed syntax, additionally js-cookie is a nice and clean for cookie setting

You will need to edit the url csrf endpoint to your implementation of the csrf url above and the uri to your graphql endpoint.

import Cookies from 'js-cookie';
import ApolloClient from 'apollo-boost';
import { InMemoryCache } from 'apollo-cache-inmemory';

const client = new ApolloClient({
    uri: '<graphql-uri>',
    // tell apollo to include credentials for csrf token protection
    credentials: 'include',
    // async operation with fetch to get csrf token
    request: async (operation) => {
      const csrftoken = await fetch('<url csrf endpoint>/csrf/')
        .then(response => response.json())
        .then(data => data.csrfToken);
     // set the cookie 'csrftoken'
      Cookies.set('csrftoken', csrftoken);
      operation.setContext({
        // set the 'X-CSRFToken' header to the csrftoken
        headers: {
          'X-CSRFToken': csrftoken,
        },
      });
    },
    cache: new InMemoryCache(),
  });

If you are using Apollo provider for the apollo link in react component:

import { ApolloProvider } from 'react-apollo';

<ApolloProvider client={client}>

With all that you should have an app that is both XSS (Httponly JWT token in a cookie) and CSRF (CSRF cookie fetch/response) secure.

@gotexis My guess is you are going to need a similar async call for your OAuth provider. You might also take a look at https://auth0.github.io/auth0.js/index.html

[Diggitysc]

Update:

So the above solution works if you are generating a single graphql call per page.

However if you are bundling (via higher order components) several graphql calls per page (such as multiple queries to display different self-contained data components) due to the asychronized nature of javascript you will likely run into a CSRF token problem as multiple requests will generate distinct csrf tokens.

A pseudo code example from hacker news clone:

// generates csrf token/post to graphql users // generates csrf token/post to graphql links

In async time:
/csrf/ is called on first components (cookie is set)
/csrf/ is called on second component (cookie is set)
component 1 fails post as csrf does not match (Forbidden)
component 2 succeeds post request

Sometimes you get lucky and
/csrf/ is called on first component (cookie is set)
component 1 succeeds post request
/csrf/ is called on second component (cookie is set)
component 2 succeeds post request

A short term solution is to re-fetch on Forbidden CSRF error, but with a bit of bad luck this can slow down page load performance as a function of the number of post requests on a page. Other work around suggestions are welcome at this point as I am a bit burnt out on the problem itself.

Long term it would be nice to have csrf token generation/checking within graphene itself in a manner that avoids these sorts of problems

[bastiW]

@Diggitysc Thanks a lot four your code.

I added a caching functionality for the csrf token. It only calls the /csrf/ api once per session.

let csrftoken;
async function getCsrfToken() {
    if (csrftoken) return csrftoken;
    csrftoken = await fetch('http://localhost:8000/csrf/')
        .then(response => response.json())
        .then(data => data.csrftoken)
    return await csrftoken
}

    const apolloClient = new ApolloClient({
        uri: httpEndpoint,
        // tell apollo to include credentials for csrf token protection
        // async operation with fetch to get csrf token
        request: async (operation) => {
            const csrftoken = await getCsrfToken();
            Cookies.set('csrftoken', csrftoken);
            // set the cookie 'csrftoken'
            operation.setContext({
                // set the 'X-CSRFToken' header to the csrftoken
                headers: {
                    'X-CSRFToken': csrftoken,
                },
            });
        },
        credentials: 'include',
        cache: new InMemoryCache(),
    })

[bastiW]

Now I also see the problem with calling two gql queries on one page. I get a 403 CSRF verification failed. Request aborted.

This happons usually on Firefox and on chrome within the incognito window