Advanced GraphQL, v2

Auth in GraphQL Overview

Scott Moss

Scott Moss

Superfilter AI
Advanced GraphQL, v2

Check out a free preview of the full Advanced GraphQL, v2 course

The "Auth in GraphQL Overview" Lesson is part of the full, Advanced GraphQL, v2 course featured in this preview video. Here's what you'd learn in this lesson:

Scott reviews the difference between authentication and authorization and how this relates to GraphQL. Authentication is used to identify a user, and authorization is used to determine if a user is allowed to perform specific operations on specific resources.


Transcript from the "Auth in GraphQL Overview" Lesson

>> The first topic we're going to talk about today now that we all know how to build a Graph API, is authentication and authorization. Anyone who wanna give me their definition of authentication?
>> Authentication is proving who you are.
>> Yeah, that's a good way to put it, authentication is proving who you are.

What about authorization?
>> Proving what you can do.
>> Proving what you can do. Well said yeah, basically. So what I have here, authentication is used to identify a user, to determine if they are who they say they are. Basically, it answers the questions of, who is this user?

Are they who they say they are? Things like that. That's the questions that authentication seeks to answer. Authorization on the other hand, is used to determine, usually an already authenticated user, if they're allowed to perform certain operations on certain resources. So for instance, you might have an RBAC system, role-based access control.

Where people have roles with different permission levels, based off different actions on different resources, that's basically authorization. You don't have the right role to either perform or delete operation on the payment resource, something like that. So those two work together, and I think when people say the word auth, generally speaking, I think they always mean authentication.

And authorization is usually something special. A lot of people might not even have authorization systems built into their application, depending on your app, it might not even be a thing. But if you have any type of multitenancy or any type of SAS app, you probably definitely have authorization because people have data scopes to themselves, and you don't want other people looking at it.

So you have to be authorized to look at your own data. So even though you might not explicitly set it up, it's implicitly implied. So let's talk about a good auth system in GraphQL. So for authorization, and this is just some stuff that I've been thinking about and things that I've come across and seen.

So let's focus on authorization. So a good auth system in GraphQL with authorization. Basically, your authorization should never be coupled to a resolver. Because one, how do you get that out and use it on another resolver? So that's gonna be kind of tough. Authorization should provide field level customization rules.

So I should be able to say, on this field, I want to be able to add some type of logic for authorization, only for this field. And it should be able to allow me to opt out from authorizing my entire schema. So I don't want to just say, locked out of my entire schema with this authorization custom logic, all right cuz it would be too flexible, especially if you have something like sign in and sign up built into your GraphQL or API.

And no one would ever be able to sign in or sign up, because they wouldn't be authorized to do it. So you don't wanna do things like that. You might also have some public query that you want to expose, and you don't want that to have any type of authorization, or anything like that.

As far as authentication, it's very similar to authorization. The one thing about authentication is, because its job is to determine if the user is who they say they are, and who the user is. The resolvers need to know who the user is in order to probably do some work, especially if you have a multitenant app.

Almost every query you're going to have inside of a resolver is going to be based off like a user ID, like give me the stuff based off this user ID, give me this stuff based off this user ID. So that means, a really good authentication system should provide the user to the resolvers.

So we don't have to worry about anything. Otherwise, the resolver is responsible for figuring out who the user is. I mean, you'd have to do that for pretty much every single resolver. That can get pretty annoying. Should not be coupled with a resolver, and it is for the same reasons authorization shouldn't be coupled with a resolver.

Can protect some of your schema and not all of it. So again, we don't want to lock down the entire schema, because we want some things to be open for everyone like update, like logging in, and signing up, and stuff like that. But we want to opt into things that we want to.

And also, we still wanna get down to the field level and say only this field, we wanna be able to lock down with authentication, and that's the only thing that matters. So to me, that is a good system of authentication, authorization or just auth in general, in GraphQL.

And I say this because I've built auth at least 2025 times in the GraphQL system. And it wasn't until like, the 10th time that I start figuring out really good patterns of like, okay, I should start doing this. But initially you start off in a way that seems easy, but it just doesn't scale.

Learn Straight from the Experts Who Shape the Modern Web

  • In-depth Courses
  • Industry Leading Experts
  • Learning Paths
  • Live Interactive Workshops
Get Unlimited Access Now