Enhance customer experiences with Apollo GraphOS

<a href="https://github.com/accounts-js/accounts">accounts-js</a>&nbsp;is a fullstack authentication and accounts-management for Javascript.&nbsp;We provide you with a set of tools to authenticate and manage your users in your application. These tools work with REST, GraphQL and are database agnostic.



We will implement the Authentication GraphQL API in NodeJS using accounts-js and Apollo. At the end of this article, our server will be able to sign up new users, allow the users to login and authenticate them to protect some restricted information.



At the end of this post, you can find a link to a repository containing the sources.



<h3 class="wp-block-heading"><a href="#requirements" aria-hidden="true" class="aal_anchor" id="requirements"><svg aria-hidden="true" class="aal_svg" height="16" version="1.1" viewBox="0 0 16 16" width="16"><path fill-rule="evenodd" d="M4 9h1v1H4c-1.5 0-3-1.69-3-3.5S2.55 3 4 3h4c1.45 0 3 1.69 3 3.5 0 1.41-.91 2.72-2 3.25V8.59c.58-.45 1-1.27 1-2.09C10 5.22 8.98 4 8 4H4c-.98 0-2 1.22-2 2.5S3 9 4 9zm9-3h-1v1h1c1 0 2 1.22 2 2.5S13.98 12 13 12H9c-.98 0-2-1.22-2-2.5 0-.83.42-1.64 1-2.09V6.25c-1.09.53-2 1.84-2 3.25C6 11.31 7.55 13 9 13h4c1.45 0 3-1.69 3-3.5S14.5 6 13 6z"></path></svg></a>Requirements</h3>



For this project, you will need to have nodejs and mongodb installed on your system.



<h3 class="wp-block-heading"><a href="#setup-the-node-project" aria-hidden="true" class="aal_anchor" id="setup-the-node-project"><svg aria-hidden="true" class="aal_svg" height="16" version="1.1" viewBox="0 0 16 16" width="16"><path fill-rule="evenodd" d="M4 9h1v1H4c-1.5 0-3-1.69-3-3.5S2.55 3 4 3h4c1.45 0 3 1.69 3 3.5 0 1.41-.91 2.72-2 3.25V8.59c.58-.45 1-1.27 1-2.09C10 5.22 8.98 4 8 4H4c-.98 0-2 1.22-2 2.5S3 9 4 9zm9-3h-1v1h1c1 0 2 1.22 2 2.5S13.98 12 13 12H9c-.98 0-2-1.22-2-2.5 0-.83.42-1.64 1-2.09V6.25c-1.09.53-2 1.84-2 3.25C6 11.31 7.55 13 9 13h4c1.45 0 3-1.69 3-3.5S14.5 6 13 6z"></path></svg></a>Setup the node project</h3>



Let&#8217;s start by creating our NodeJS project. Create a new folder named&nbsp;<code class="" data-line="">accounts-js-server</code>, all the project files should be inside this folder. Let&#8217;s initialize our new project using&nbsp;<code class="" data-line="">npm</code>&nbsp;(you can use&nbsp;<code class="" data-line="">yarn</code>&nbsp;if you prefer):



<pre class="wp-block-prismatic-blocks"><code class="" data-line="">npm init</code></pre>



Now, let&#8217;s add the dependencies we need to setup our Apollo GraphQL server.



<pre class="wp-block-prismatic-blocks"><code class="" data-line="">npm install apollo-server graphql</code></pre>



Create a new&nbsp;<code class="" data-line="">index.js</code>&nbsp;file (to make this tutorial simpler all our code will be in a single file) and add this code to setup the Apollo server.



<pre class="wp-block-prismatic-blocks"><code class="language-javascript" data-line="">// index.js

const { ApolloServer, gql } = require(&#039;apollo-server&#039;);

const typeDefs = gql`
 type Query {
 # This query will be protected so only authenticated users can access it
 sensitiveInformation: String
 }
`;

const resolvers = {
 Query: {
 sensitiveInformation: () =&gt; &#039;Sensitive info&#039;,
 },
};

const server = new ApolloServer({ typeDefs, resolvers });

// The `listen` method launches a web server.
server.listen().then(({ url }) =&gt; {
 console.log(`🚀 Server ready at ${url}`);
});</code></pre>



Now let&#8217;s start the server to make sure everything is working as expected.



<pre class="wp-block-prismatic-blocks"><code class="" data-line="">node index.js</code></pre>



In your console you should see:



<pre class="wp-block-prismatic-blocks"><code class="" data-line="">🚀 Server ready at http://localhost:4000/</code></pre>



Our GraphQL server is now ready, it&#8217;s time to add accounts-js!



<h3 class="wp-block-heading"><a href="#setup-accounts-js" aria-hidden="true" class="aal_anchor" id="setup-accounts-js"><svg aria-hidden="true" class="aal_svg" height="16" version="1.1" viewBox="0 0 16 16" width="16"><path fill-rule="evenodd" d="M4 9h1v1H4c-1.5 0-3-1.69-3-3.5S2.55 3 4 3h4c1.45 0 3 1.69 3 3.5 0 1.41-.91 2.72-2 3.25V8.59c.58-.45 1-1.27 1-2.09C10 5.22 8.98 4 8 4H4c-.98 0-2 1.22-2 2.5S3 9 4 9zm9-3h-1v1h1c1 0 2 1.22 2 2.5S13.98 12 13 12H9c-.98 0-2-1.22-2-2.5 0-.83.42-1.64 1-2.09V6.25c-1.09.53-2 1.84-2 3.25C6 11.31 7.55 13 9 13h4c1.45 0 3-1.69 3-3.5S14.5 6 13 6z"></path></svg></a>Setup accounts-js</h3>



First, we will setup mongoose and connect to our database.



<pre class="wp-block-prismatic-blocks"><code class="" data-line="">npm install @accounts/mongo mongoose</code></pre>



<pre class="wp-block-prismatic-blocks"><code class="language-javascript" data-line="">// index.js

const mongoose = require(&#039;mongoose&#039;);
const { Mongo } = require(&#039;@accounts/mongo&#039;);

// We connect mongoose to our local mongodb database
mongoose.connect(&#039;mongodb://localhost:27017/accounts-js-server&#039;, {
 useNewUrlParser: true,
 useUnifiedTopology: true,
});

// We tell accounts-js to use the mongo connection
const accountsMongo = new Mongo(mongoose.connection);</code></pre>



Then, we add the accounts-js server dependencies.



<pre class="wp-block-prismatic-blocks"><code class="" data-line="">npm install @accounts/server @accounts/password</code></pre>



<ul class="wp-block-list"><li><code class="" data-line="">@accounts/server</code>: The accounts-js core dependency.</li><li><code class="" data-line="">@accounts/password</code>: The accounts-js password service, it expose a set of function to manage and authenticate users using email + password.</li></ul>



It&#8217;s time to setup the accounts-js server configuration



<pre class="wp-block-prismatic-blocks"><code class="language-javascript" data-line="">// index.js

const { AccountsServer } = require(&#039;@accounts/server&#039;);
const { AccountsPassword } = require(&#039;@accounts/password&#039;);

const accountsPassword = new AccountsPassword({
 // You can customise the behavior of the password service by providing some options
});

const accountsServer = new AccountsServer(
 {
 // We link the mongo adapter we created in the previous step to the server
 db: accountsMongo,
 // Replace this value with a strong random secret
 tokenSecret: &#039;my-super-random-secret&#039;,
 },
 {
 // We pass a list of services to the server, in this example we just use the password service
 password: accountsPassword,
 }
);</code></pre>



Then, we add the accounts-js graphql dependencies.



<pre class="wp-block-prismatic-blocks"><code class="" data-line="">npm install @accounts/graphql-api @graphql-toolkit/schema-merging @graphql-modules/core</code></pre>



<ul class="wp-block-list"><li><code class="" data-line="">@accounts/graphql-api</code>: The transport layer exposing all the queries and mutations accounts-js provide.</li><li><code class="" data-line="">@graphql-toolkit/schema-merging</code>: Expose a set of tools that will help us to merge our schemas.</li><li><code class="" data-line="">@graphql-modules/core</code>: An internal dependency that accounts-js use to manage his graphql schema and resolvers.</li></ul>



Let&#8217;s merge the accounts-js GraphQL schema and our schema, so the user can access it



<pre class="wp-block-prismatic-blocks"><code class="language-javascript" data-line="">// index.js

// Add makeExecutableSchema to the imported variables
const { ApolloServer, gql, makeExecutableSchema } = require(&#039;apollo-server&#039;);
const { mergeTypeDefs, mergeResolvers } = require(&#039;@graphql-toolkit/schema-merging&#039;);
const { AccountsModule } = require(&#039;@accounts/graphql-api&#039;);

// We generate the accounts-js GraphQL module
const accountsGraphQL = AccountsModule.forRoot({ accountsServer });

// A new schema is created combining our schema and the accounts-js schema
const schema = makeExecutableSchema({
 typeDefs: mergeTypeDefs([typeDefs, accountsGraphQL.typeDefs]),
 resolvers: mergeResolvers([accountsGraphQL.resolvers, resolvers]),
 schemaDirectives: {
 ...accountsGraphQL.schemaDirectives,
 },
});

// When we instantiate our Apollo server we use the schema and context properties
const server = new ApolloServer({
 schema,
 context: accountsGraphQL.context,
});</code></pre>



At the end, our file should look like this:



<pre class="wp-block-prismatic-blocks"><code class="language-javascript" data-line="">// index.js

const { ApolloServer, gql, makeExecutableSchema } = require(&#039;apollo-server&#039;);
const mongoose = require(&#039;mongoose&#039;);
const { Mongo } = require(&#039;@accounts/mongo&#039;);
const { mergeTypeDefs, mergeResolvers } = require(&#039;@graphql-toolkit/schema-merging&#039;);
const { AccountsServer } = require(&#039;@accounts/server&#039;);
const { AccountsPassword } = require(&#039;@accounts/password&#039;);
const { AccountsModule } = require(&#039;@accounts/graphql-api&#039;);

// We connect mongoose to our local mongodb database
mongoose.connect(&#039;mongodb://localhost:27017/accounts-js-server&#039;, {
 useNewUrlParser: true,
 useUnifiedTopology: true,
});

const accountsMongo = new Mongo(mongoose.connection);

const typeDefs = gql`
 type Query {
 # This query will be protected so only authenticated users can access it
 sensitiveInformation: String
 }
`;

const resolvers = {
 Query: {
 sensitiveInformation: () =&gt; &#039;Sensitive info&#039;,
 },
};

const accountsPassword = new AccountsPassword({});

const accountsServer = new AccountsServer(
 {
 db: accountsMongo,
 // Replace this value with a strong secret
 tokenSecret: &#039;my-super-random-secret&#039;,
 },
 {
 password: accountsPassword,
 }
);

// We generate the accounts-js GraphQL module
const accountsGraphQL = AccountsModule.forRoot({ accountsServer });

// A new schema is created combining our schema and the accounts-js schema
const schema = makeExecutableSchema({
 typeDefs: mergeTypeDefs([typeDefs, accountsGraphQL.typeDefs]),
 resolvers: mergeResolvers([accountsGraphQL.resolvers, resolvers]),
 schemaDirectives: {
 ...accountsGraphQL.schemaDirectives,
 },
});

const server = new ApolloServer({ schema, context: accountsGraphQL.context });

// The `listen` method launches a web server.
server.listen().then(({ url }) =&gt; {
 console.log(`🚀 Server ready at ${url}`);
});</code></pre>



If we restart our server and visit http://localhost:4000/, we should see that the accounts-js queries and mutations are merged with our schema. Our authentication server is now ready 🚀.



<figure class="wp-block-image size-large"><img loading="lazy" decoding="async" width="1024" height="632" src="https://wp.apollographql.com/wp-content/uploads/2020/05/ud3ptilvz38a2k7pizs2-1024x632.png" alt="" class="wp-image-2160" srcset="https://wp.apollographql.com/wp-content/uploads/2020/05/ud3ptilvz38a2k7pizs2-1024x632.png 1024w, https://wp.apollographql.com/wp-content/uploads/2020/05/ud3ptilvz38a2k7pizs2-300x185.png 300w, https://wp.apollographql.com/wp-content/uploads/2020/05/ud3ptilvz38a2k7pizs2-768x474.png 768w, https://wp.apollographql.com/wp-content/uploads/2020/05/ud3ptilvz38a2k7pizs2-1200x740.png 1200w, https://wp.apollographql.com/wp-content/uploads/2020/05/ud3ptilvz38a2k7pizs2.png 1277w" sizes="auto, (max-width: 1024px) 100vw, 1024px" /></figure>



<h3 class="wp-block-heading"><a href="#creating-our-first-user" aria-hidden="true" class="aal_anchor" id="creating-our-first-user"><svg aria-hidden="true" class="aal_svg" height="16" version="1.1" viewBox="0 0 16 16" width="16"><path fill-rule="evenodd" d="M4 9h1v1H4c-1.5 0-3-1.69-3-3.5S2.55 3 4 3h4c1.45 0 3 1.69 3 3.5 0 1.41-.91 2.72-2 3.25V8.59c.58-.45 1-1.27 1-2.09C10 5.22 8.98 4 8 4H4c-.98 0-2 1.22-2 2.5S3 9 4 9zm9-3h-1v1h1c1 0 2 1.22 2 2.5S13.98 12 13 12H9c-.98 0-2-1.22-2-2.5 0-.83.42-1.64 1-2.09V6.25c-1.09.53-2 1.84-2 3.25C6 11.31 7.55 13 9 13h4c1.45 0 3-1.69 3-3.5S14.5 6 13 6z"></path></svg></a>Creating our first user</h3>



Inside the GraphQL Playground, let&#8217;s execute the following mutation:



<pre class="wp-block-prismatic-blocks"><code class="language-graphql" data-line="">mutation {
 createUser(
 user: { email: &quot;john.doe@john.com&quot;, password: &quot;superSecurePassword&quot; }
 )
}</code></pre>



Congrats, our first user has been created 👏!



If you take a look at the&nbsp;<code class="" data-line="">users</code>&nbsp;collection inside mongodb you should see that your user was created and looks like this:



<pre class="wp-block-prismatic-blocks"><code class="language-json" data-line="">{
 &quot;_id&quot;: ObjectId(&quot;5e3da6ba13ef1a137bbc8fe4&quot;),
 &quot;services&quot;: {
 &quot;password&quot;: {
 &quot;bcrypt&quot;: &quot;$2a$10$WwhjvbDzQpS2LrdkcgQJwODn.EE95T0b9NmMUNcHKyrDOlXEeybSq&quot;
 }
 },
 &quot;createdAt&quot;: 1581098682713,
 &quot;updatedAt&quot;: 1581098682713,
 &quot;emails&quot;: [
 {
 &quot;address&quot;: &quot;john.doe@john.com&quot;,
 &quot;verified&quot;: false
 }
 ]
}
</code></pre>



What we can see is that a&nbsp;<code class="" data-line="">createdAt</code>&nbsp;and&nbsp;<code class="" data-line="">updatedAt</code>&nbsp;fields have been created. We also see that the password has been saved hashed in the database, we use bcrypt as a default but you can change it to argon2 via the options if you prefer.



Now let&#8217;s try to login with this user:



<pre class="wp-block-prismatic-blocks"><code class="language-graphql" data-line="">mutation {
 authenticate(
 serviceName: &quot;password&quot;
 params: {
 user: { email: &quot;john.doe@john.com&quot; }
 password: &quot;superSecurePassword&quot;
 }
 ) {
 sessionId
 tokens {
 accessToken
 refreshToken
 }
 }
}</code></pre>



You should see in the playground that a new session has been created. The session is represented by:



<ul class="wp-block-list"><li>a sessionId (you can check the session in the database)</li><li>a short lived JWT accessToken used to authenticate the user</li><li>a long lived refreshToken that can be used to get a new accessToken once it&#8217;s expired</li></ul>



Save the access token, we will need it to authenticate our requests in the next part.



<h3 class="wp-block-heading"><a href="#protecting-our-query" aria-hidden="true" class="aal_anchor" id="protecting-our-query"><svg aria-hidden="true" class="aal_svg" height="16" version="1.1" viewBox="0 0 16 16" width="16"><path fill-rule="evenodd" d="M4 9h1v1H4c-1.5 0-3-1.69-3-3.5S2.55 3 4 3h4c1.45 0 3 1.69 3 3.5 0 1.41-.91 2.72-2 3.25V8.59c.58-.45 1-1.27 1-2.09C10 5.22 8.98 4 8 4H4c-.98 0-2 1.22-2 2.5S3 9 4 9zm9-3h-1v1h1c1 0 2 1.22 2 2.5S13.98 12 13 12H9c-.98 0-2-1.22-2-2.5 0-.83.42-1.64 1-2.09V6.25c-1.09.53-2 1.84-2 3.25C6 11.31 7.55 13 9 13h4c1.45 0 3-1.69 3-3.5S14.5 6 13 6z"></path></svg></a>Protecting our query</h3>



Our first user has been created and we are now able to login via the API. Next step is to protect our&nbsp;<code class="" data-line="">sensitiveInformation</code>&nbsp;query so only the authenticated users can access it.



accounts-js provide an&nbsp;<code class="" data-line="">@auth</code>&nbsp;directive that we can use to protect our private queries.



Let&#8217;s add the directive to the query in our schema:



<pre class="wp-block-prismatic-blocks"><code class="language-javascript" data-line="">// index.js

const typeDefs = gql`
 type Query {
 # We add the @auth directive
 sensitiveInformation: String @auth
 }
`;</code></pre>



If you try this query, you should get an&nbsp;<code class="" data-line="">Unauthorized</code>&nbsp;error 🛑. We can&#8217;t access this resource because we are not authenticated. To authenticate our request with the server we need to add the access token saved previously as a header of the request. The header key should be&nbsp;<code class="" data-line="">authorization</code>&nbsp;and the value should be prefixed with&nbsp;<code class="" data-line="">Bearer</code>. eg:&nbsp;<code class="" data-line="">{ &quot;authorization&quot;: &quot;Bearer my-access-token&quot; }</code>



<figure class="wp-block-image size-large"><img loading="lazy" decoding="async" width="1024" height="630" src="https://wp.apollographql.com/wp-content/uploads/2020/05/tkat54liy7txdsf8aa08-1024x630.png" alt="" class="wp-image-2170" srcset="https://wp.apollographql.com/wp-content/uploads/2020/05/tkat54liy7txdsf8aa08-1024x630.png 1024w, https://wp.apollographql.com/wp-content/uploads/2020/05/tkat54liy7txdsf8aa08-300x185.png 300w, https://wp.apollographql.com/wp-content/uploads/2020/05/tkat54liy7txdsf8aa08-768x472.png 768w, https://wp.apollographql.com/wp-content/uploads/2020/05/tkat54liy7txdsf8aa08-1200x738.png 1200w, https://wp.apollographql.com/wp-content/uploads/2020/05/tkat54liy7txdsf8aa08.png 1281w" sizes="auto, (max-width: 1024px) 100vw, 1024px" /></figure>



You made your first authenticated query, how cool is that?



Well, that&#8217;s it, you are done, you now have a Graphql server that can register and authenticate new users. Pretty simple right? Next step for you is to explore the playground and play with the different queries and mutations available (verify the email, change the password etc..) :).



You can find the source here&nbsp;<a href="https://github.com/pradel/accounts-js-server-tutorial">https://github.com/pradel/accounts-js-server-tutorial</a>.



If you want to learn more about accounts-js head over our website and check the documentation <a href="https://www.accountsjs.com/">https://www.accountsjs.com/</a> 🔐.

Email & password authentication with accounts-js and Apollo Server

Setting Up Authentication and Authorization with Apollo Federation

Authorization in GraphQL

Access Control in GraphQL

Note: If you’re not yet familiar with GraphQL, take a look at my&nbsp;<a href="https://medium.com/apollo-stack/the-basics-of-graphql-in-5-links-9e1dc4cac055" target="_blank" rel="noreferrer noopener">other post</a>&nbsp;first and come back later — you’ll get more out of it.



Update 2018:&nbsp;This post is from early 2016. Check out the&nbsp;<a href="https://www.apollographql.com/docs/guides/access-control.html" target="_blank" rel="noreferrer noopener">best practices we recommend for authentication and authorization.</a>



In this post, I want to talk about how you might go about authentication and authorization when using GraphQL. The examples I’m giving work for graphql-js, Facebook’s reference implementation, but they are quite generic and could be adapted to other implementations as well.



Before we get started, let’s make sure we’re all on the same page when it comes to the terms I’ll be using:



Authentication&nbsp;means checking the identity of the user making a request.



Authorization&nbsp;refers to the set of rules that is applied to determine what a user is allowed to see / do.



The GraphQL specification doesn’t tell you how to do authentication or authorization. That’s a good thing because it lets you use any technology you like, but it can be a bit confusing to developers who are new to GraphQL. For the rest of this post, I will write my thoughts on the topic so far and show a few options for authentication and authorization. GraphQL is still relatively new, so a best practice has yet to emerge. I don’t claim to have all the answers, so if you have a different idea or a different opinion, feel free to share that in the comments so we can all learn together!



Alright, that’s enough disclaimers for now. Let’s get started…



<h2 class="wp-block-heading" id="844e"><a href="#authentication" aria-hidden="true" class="aal_anchor" id="authentication"><svg aria-hidden="true" class="aal_svg" height="16" version="1.1" viewBox="0 0 16 16" width="16"><path fill-rule="evenodd" d="M4 9h1v1H4c-1.5 0-3-1.69-3-3.5S2.55 3 4 3h4c1.45 0 3 1.69 3 3.5 0 1.41-.91 2.72-2 3.25V8.59c.58-.45 1-1.27 1-2.09C10 5.22 8.98 4 8 4H4c-.98 0-2 1.22-2 2.5S3 9 4 9zm9-3h-1v1h1c1 0 2 1.22 2 2.5S13.98 12 13 12H9c-.98 0-2-1.22-2-2.5 0-.83.42-1.64 1-2.09V6.25c-1.09.53-2 1.84-2 3.25C6 11.31 7.55 13 9 13h4c1.45 0 3-1.69 3-3.5S14.5 6 13 6z"></path></svg></a>Authentication</h2>



Unless your GraphQL API is completely public, your server will need to authenticate its users. Your options are twofold:



<ol class="wp-block-list"><li>Let the web server (e.g. express or nginx) take care of authentication.</li><li>Handle authentication in GraphQL itself.</li></ol>



Both of these options have some advantages and some disadvantages.



If you do authentication in the web server, you can use a standard auth package (e.g. passport.js for express) and many existing authentication methods will work out of the box. You can also add and remove methods at your liking without modifying the GraphQL schema.



However, doing authentication in the web server has the downside of requiring the client to speak to an authentication endpoint in addition to the GraphQL endpoint.



<hr class="wp-block-separator"/>



Let’s start with the first option: doing authentication in the web server. What would that look like?



It’s quite straight forward. If you’re using express for example, you could use a middleware like passport.js and any authentication strategy it supports, for example username+password, or OAuth. The middleware will authenticate the user or reject/redirect the request if it fails. You’ll have to provide the requisite methods for persisting users and expose the login endpoints, but I’ll spare you the details — if you need them, you can look them up in the middleware’s documentation.



Once the user is authenticated, you simply pass the user information into GraphQL as context. If you were using express, graphql-js and passport.js, that would look something like this:



<pre class="wp-block-preformatted">import { Schema } from ‘./schema/schema.js’; //your GraphQL schema import { graphql } from ‘graphql’; import bodyParser from ‘body-parser’; import express from ‘express’; import passport from ‘passport’; import session from ‘express-session’; import uuid from ‘node-uuid’;require(‘./auth.js’); //see snippet belowconst app = express(); const PORT = 3000;//passport's session piggy-backs on express-session app.use(session({ genid: function(req) { return uuid.v4(); }, secret: ‘Z3]GJW!?9uP”/Kpe’ }));app.use(passport.initialize()); app.use(passport.session());app.post('/graphql', (req, res) =&gt; { graphql(schema, req.body, { user: req.user }) .then((data) =&gt; { res.send(JSON.stringify(data)); }); });//login route for passport app.use(bodyParser.urlencoded({ extended: true }) ); app.post('/login', passport.authenticate('local', { successRedirect: '/', failureRedirect: '/login', failureFlash: true }) );app.listen(PORT, () =&gt; { console.log(“GraphQL server listening on port %s”, PORT); });</pre>



And in&nbsp;auth.js:



<pre class="wp-block-preformatted">import passport from ‘passport’; let LocalStrategy = require(‘passport-local’).Strategy;import {DB} from ‘./schema/db.js’;passport.use(‘local’, new LocalStrategy( function(username, password, done) { let checkPassword = DB.Users.checkPassword( username, password); let getUser = checkPassword.then( (is_login_valid) =&gt; { if(is_login_valid){ return DB.Users.getUserByUsername( username ); } else { throw new Error(“invalid username or password”); } }) .then( ( user ) =&gt; { return done(null, user); }) .catch( (err) =&gt; { return done(err); }); } ));passport.serializeUser(function(user, done) { done(null, user.id); });passport.deserializeUser(function(id, done) { DB.Users.get(id).then( (user, err) =&gt; { return done(err, user); }); });</pre>



And voila, you now have access to the user object in the GraphQL resolver!



<hr class="wp-block-separator"/>



Alright, now let’s look at the second option: doing authentication in GraphQL. What would that look like?



A word of caution here:&nbsp;If you’re implementing authentication yourself, make sure to never store passwords in clear text or a MD5 or SHA-256 hash. Use something like bcrypt that is designed for this kind of thing. While we’re at it, make sure to not store your session tokens as-is on the server, you should hash them first.



Here, things get a little bit more complicated, because you have to do more of the heavy lifting yourself. To keep it at least reasonably simple, let’s go with usernames and passwords in this example. So an authentication flow could look like this:



First you get a session token (so your client doesn’t have to store the username and password in cleartext):



<pre class="wp-block-preformatted">mutation { getSessionToken(username: 'alice', password: 'hard2remember') } &gt; { getSessionToken: "6e37a03e-9ee4-42fd-912d-3f67d2d0d852" }</pre>



Then you pass this token in subsequent requests:



<pre class="wp-block-preformatted">query { user(token: "6e37a03e-9ee4-42fd-912d-3f67d2d0d852"){ todoLists{ name } } }&gt; { user { todoLists: [ "Today", "Tomorrow" ] } }</pre>



When your session is over, you can call a logout mutation which invalidates the session token.



On the surface, this looks quite reasonable, but it has some downsides:



<ul class="wp-block-list"><li>Every query or mutation that needs permissions has to add the token field and check it. That can be a lot of repetition, if your schema is complex.</li><li>If any field besides your root queries need to be aware of the token, you have to pass it down by returning it from each resolver. So for example, if the todoLists needed to be filtered based on the logged in user, you would have to do the following:</li></ul>



<pre class="wp-block-preformatted">user: { resolve: (root, {token}){ return { token: token, user: /*...*/ }; } },/* ... */todoLists: { resolve: (parent) =&gt; { let user = parent.user; let token = parent.token; /* Return lists filtered based on token ... */ } }</pre>



That looks bad enough, but if you need the token further down, it gets even worse. If your resolver returns a GraphQLList type, you’ll have to add the token to every item in that list.



Luckily, there’s a slightly better way in graphql-js: You can set the token on the context that every resolver receives as its third argument:



<pre class="wp-block-preformatted">user: { resolve: (root, {token}, ctx){ ctx.token = token; //assuming ctx is already an object return { /* user */ }; } }</pre>



If you are doing multiple queries, you will still have to pass the token into each one, because they get executed in parallel. In that case, writing to the context is also not a great idea any more. There is however a neat trick — or an awful hack, depending on who you ask — you can use, but it only works for mutations:



You can write a login method, which sets the context. Since mutations are executed one after the other and not in parallel, you can be sure the context is set after the login mutation:



<pre class="wp-block-preformatted">mutation { loginWithToken(token: "6e37a03e-9ee4-42fd-912d-3f67d2d0d852"), do_stuff(greeting: "Hello", name: "Tom"), do_more_stuff(submarine_color: "Yellow") }</pre>



I’ll let you in on a secret here, but please don’t shoot yourself in the foot with it: There is no difference between mutations and queries, except that mutations are executed serially, in the order given. That means the second mutation has to wait for the first to finish, the third has to wait for the second to finish, and so on. But there is nothing that prevents you from mutating state in your queries, and there is nothing that prevents you from calling a query a mutation.



That said, I would not recommend calling everything a mutation just to use the above trick. Parallel execution is an important for performance.



As you can see, this approach is not very elegant, and the workaround writes the token to the context, just like the web server would. There may be cases where you cannot modify the web server and you’re forced to do authentication in GraphQL, but in most cases I think I would prefer to handle authentication in the web server. It’s not only more generic, but also more flexible.



<hr class="wp-block-separator"/>



That’s all for now. Originally I was planning to write about authentication and authorization in the same post, but it was getting a little long so I decided to break it up. If you liked this post, make sure to also read&nbsp;<a href="https://medium.com/apollo-stack/auth-in-graphql-part-2-c6441bcc4302" target="_blank" rel="noreferrer noopener">Part 2</a>!



I’m also working towards a complete example app to showcase all language features of GraphQL and how to use them in practice. It will include authentication and authorization as well as a bunch of other things. I‘m looking for collaborators on that, so if you’re interested, do let me know. The more, the merrier!



As always, discussion and feedback is very welcome. Just leave your comments below!

Backend

Email & password authentication with accounts-js and Apollo Server

Setting Up Authentication and Authorization with Apollo Federation

Authorization in GraphQL

Access Control in GraphQL

A guide to authentication in GraphQL

Backend

Email & password authentication with accounts-js and Apollo Server

Setting Up Authentication and Authorization with Apollo Federation

Authorization in GraphQL

Access Control in GraphQL

A guide to authentication in GraphQL

Stay in our orbit