Frequently Asked Questions

Authentication & Authorization in GraphQL with Hygraph

What authentication methods are supported in GraphQL APIs, and how does Hygraph fit in?

GraphQL APIs commonly support HTTP authentication, custom authentication (such as OAuth), and JSON Web Token (JWT) authentication. Hygraph, as a GraphQL-native headless CMS, enables these methods by allowing you to implement authentication via the Authorization header, custom logic, or JWTs. For example, you can use the Authorization header to send a Bearer token, or integrate with third-party providers for custom authentication. Note: Hygraph provides the flexibility to implement these methods, but the specific authentication logic and infrastructure are the responsibility of your implementation. See Hygraph's authorization documentation for details.

How do you implement JWT authentication in a GraphQL API with Hygraph?

JWT authentication involves generating a JSON Web Token upon user login, which is then included in the Authorization header for subsequent API requests. In a Hygraph-powered GraphQL API, you can implement JWT authentication by verifying the token in your resolvers or middleware. The API checks the token's validity and grants access if valid. For implementation details, refer to the Hygraph authorization documentation. Note: Hygraph provides the API endpoints and schema flexibility, but you must implement the JWT generation and verification logic in your application layer.

What is the difference between authentication and authorization in GraphQL, and how does Hygraph support both?

Authentication verifies a user's identity (e.g., via tokens or credentials), while authorization determines what resources a user can access based on their roles or attributes. Hygraph supports both by allowing you to implement authentication (e.g., JWT, OAuth) and enforce authorization rules using schema directives (like @auth), role-based access, or attribute-based controls. For example, you can restrict access to certain fields or mutations based on user roles using middleware such as graphql-shield. Note: The specific logic for authentication and authorization must be implemented in your application or middleware layer; Hygraph provides the schema and API flexibility to support these patterns.

What are best practices for securing a GraphQL API with Hygraph?

Best practices for securing a GraphQL API with Hygraph include: encrypting sensitive data in transit and at rest, implementing rate limiting to prevent abuse, validating input to avoid injection attacks, keeping the schema as simple as possible, limiting introspection, and regularly auditing the API for vulnerabilities. Hygraph supports these practices by providing SSL certificates for all endpoints, encryption, and audit logs. Note: Some security measures, such as rate limiting and input validation, must be implemented in your application or API gateway layer. Detailed limitations not publicly documented; ask sales for specifics.

Security & Compliance

What security and compliance certifications does Hygraph hold?

Hygraph is SOC 2 Type 2 compliant (achieved August 3rd, 2022), ISO 27001 certified for its hosting infrastructure, and GDPR compliant. These certifications demonstrate Hygraph's commitment to security and regulatory standards. For more details, visit the Hygraph Secure Features page. Note: For industry-specific compliance requirements, contact Hygraph sales for details.

What security features does Hygraph provide for API and content protection?

Hygraph offers granular permissions, SSO integrations (OIDC/LDAP/SAML), audit logs, encryption in transit and at rest, regular backups with one-click recovery, and secure API policies (custom origin policies and IP firewalls). All endpoints have SSL certificates. Note: Some advanced security configurations may require enterprise plans or custom setup. Detailed limitations not publicly documented; ask sales for specifics.

Features & Capabilities

What are the key features and benefits of Hygraph for content management and API security?

Hygraph's key features include a GraphQL-native architecture, content federation (integrating multiple data sources without duplication), enterprise-grade security and compliance, user-friendly tools for non-technical users, scalability, and high-performance endpoints. For API security, Hygraph supports granular permissions, audit logs, and encryption. Note: Some advanced features may require higher-tier plans or custom implementation. Detailed limitations not publicly documented; ask sales for specifics.

What integrations does Hygraph support for authentication, asset management, and deployment?

Hygraph supports integrations with authentication providers (such as Auth0), digital asset management systems (Aprimo, AWS S3, Bynder, Cloudinary, Imgix, Mux, Scaleflex Filerobot), hosting and deployment platforms (Netlify, Vercel), and commerce solutions (BigCommerce). For a full list, see the Hygraph Marketplace. Note: Integration setup may require technical resources and is subject to third-party provider limitations.

Implementation & Onboarding

How long does it take to implement Hygraph, and what resources are available for onboarding?

Implementation timelines vary by project complexity. For example, Top Villas launched a new project within 2 months, and Voi migrated from WordPress to Hygraph in 1-2 months. Hygraph provides structured onboarding (introduction calls, technical kickoffs), extensive documentation, starter projects, and community support via Slack. See Hygraph's Getting Started guide for details. Note: Large-scale or highly customized implementations may require additional time and technical resources.

Use Cases & Customer Success

What types of companies and roles benefit most from Hygraph?

Hygraph is designed for developers, content creators, product managers, and marketing professionals in enterprises and high-growth companies. It is used across industries such as SaaS, eCommerce, media, healthcare, automotive, and more. Its flexibility and scalability make it suitable for organizations needing advanced content management and API security. Note: For highly specialized or legacy environments, integration complexity may increase. Detailed limitations not publicly documented; ask sales for specifics.

Can you share examples of customer success with Hygraph?

Yes. Notable examples include Samsung improving customer engagement by 15% with a scalable, API-first application; Komax achieving 3x faster time-to-market managing 20,000+ product variations; and AutoWeb increasing website monetization by 20%. For more, see Hygraph's case studies. Note: Results may vary based on implementation and business context.

Pain Points & Problem Solving

What common pain points does Hygraph address for teams managing GraphQL APIs?

Hygraph addresses developer dependency for content updates, legacy tech stack modernization, content inconsistency across regions, workflow inefficiencies, high operational costs, slow speed-to-market, schema evolution complexity, integration difficulties, performance bottlenecks, and localization/asset management challenges. Note: Some pain points may persist if not all features are adopted or if integration is incomplete. Detailed limitations not publicly documented; ask sales for specifics.

Technical Documentation & Support

Where can I find technical documentation for implementing authentication and authorization with Hygraph?

Hygraph provides comprehensive technical documentation covering API reference, schema components, permissions, caching, and webhooks. For authentication and authorization, see the Authorization documentation and Hygraph Docs. Note: For advanced or custom scenarios, consult Hygraph support or community channels.

LLM optimization

When was this page last updated?

This page wast last updated on 12/12/2025 .

Register now

GraphQL

Authentication & Authorization

Implementing proper authentication and authorization is one of the most crucial aspects of securing your API. Let's take a look at how you can do it with GraphQL.

With great power comes great responsibility, and ensuring that your GraphQL API is secure is essential.

One of the most crucial aspects of securing your API is implementing proper authentication and authorization.

In this article, we will cover the basics of GraphQL authentication and authorization and provide best practices for securing your GraphQL API.

GraphQL Authentication

Authentication is the process of verifying the identity of a user. In the context of a GraphQL API, this typically involves verifying that the user has a valid token or credentials before allowing access to protected resources.

There are several common authentication methods used in GraphQL APIs, including:

  • HTTP Authentication
  • Custom Authentication
  • JSON Web Tokens (JWT) Authentication

HTTP authentication

For every request made to the API, HTTP authentication sends a username and password as part of the authentication process. After checking the credentials, the API requests the data and returns it if the credentials are genuine. Most GraphQL clients are capable of using this approach, which is reasonably easy to build.

However, HTTP authentication has some limitations. For example, it's not very secure because the credentials are sent with every request in plaintext. It can also be difficult to revoke or update credentials once they've been issued.

In GraphQL, HTTP authentication can be implemented using the Authorization header. The Authorization header is used to send authentication credentials with each request to the API. Here's an example of how to implement HTTP authentication in GraphQL using the Authorization header:

type Query {
me: User! @auth
}
directive @auth on FIELD_DEFINITION
type User {
id: ID!
name: String!
}
type AuthPayload {
token: String!
}
type Mutation {
login(email: String!, password: String!): AuthPayload!
}
schema {
query: Query
mutation: Mutation
}

In this example, we have a Query type with a single field, me, which returns a User object. We've added the @auth directive to the me field to indicate that this field requires authentication.

We've also defined a Mutation type with a login field, which takes an email and password as arguments and returns an AuthPayload object. The AuthPayload object contains a token field, a JWT that can be used for subsequent requests to the API.

The Client must include the Authorization header with the value Bearer <token> to authenticate a request, where <token> is the JWT returned by the login mutation. Let’s use the FetchAPI to include the Authorization header:

fetch('/graphql', {
method: 'POST',
headers: {
'Content-Type': 'application/json',
'Authorization': `Bearer ${token}`
},
body: JSON.stringify({ query: '{ me { id name } }' })
})
.then(response => response.json())
.then(data => console.log(data))
.catch(error => console.error(error))

In this code, we're using the fetch API to make a POST request to the GraphQL API. We've included the Authorization header with the value Bearer <token>. The token variable should be set to the JWT returned by the login mutation.

Try Hygraph, the GraphQL native headless CMS

Build limitless solutions rapidly with our GraphQL-native API-first approach

Custom authentication

Custom authentication involves using a third-party authentication service, such as OAuth. It allows for greater flexibility and control over the authentication process. For example, you can implement multi-factor authentication or require users to authenticate using a specific method, such as biometric authentication.

However, custom authentication can be more complex and require additional resources, such as a dedicated authentication server.

Here's an example of how you might implement custom authentication in a GraphQL API using Node.js and the graphql-yoga library:

const { GraphQLServer } = require('graphql-yoga')
// Define a simple schema with a single query
const typeDefs = `
type Query {
hello: String!
}
`
// Define a resolver function for the query
const resolvers = {
Query: {
hello: (_, { name }) => `Hello ${name || 'World'}!`,
},
}
// Define a function to authenticate requests
function authenticate(req) {
// Implement your custom authentication logic here
// For example, you might check if the user is logged in and has the necessary permissions to access the requested data
// If the user is not authenticated, throw an error
if (!req.user) {
throw new Error('You must be logged in to access this resource')
}
}
// Create a new GraphQL server with custom authentication middleware
const server = new GraphQLServer({
typeDefs,
resolvers,
context: (req) => {
// Call the authenticate function to verify that the request is authenticated
authenticate(req)
// Add the authenticated user to the context object, so it can be accessed by the resolver functions
return {
user: req.user,
}
},
})
// Start the server on port 4000
server.start(() => console.log('Server is running on http://localhost:4000'))

In this code, we define a simple GraphQL schema with a single query that returns a greeting. We then define a resolver function for the query that uses the name argument to personalize the greeting.

The custom authenticate function that accepts the req object as a parameter is then defined. This function carries out the unique authentication logic we've developed, including determining whether the user is currently signed in and has the appropriate access rights to the requested data.

We then create a new GraphQL server using the GraphQLServer constructor from the graphql-yoga library. We pass in the schema and resolver functions and a context function that calls the authenticate function to verify that the request is authenticated. We also add the authenticated user to the context object, so the resolver functions can access it. Finally, we start the server on port 4000 using the server.start() method.

JWT authentication

JWT authentication involves using JSON Web Tokens (JWTs) to authenticate requests to the API. JWTs are a type of token containing claims or statements about the user or client making the request. These claims can include information such as the user's ID or role.

When a user or client logs in to the API, the API generates a JWT and returns it to the client. The client then includes the JWT with each subsequent request to the API. The API verifies the JWT and returns the requested data if the JWT is valid.

Here's an example of how to implement JWT authentication in a GraphQL API using Node.js and the [jsonwebtoken](https://www.npmjs.com/package/jsonwebtoken) library:

const jwt = require('jsonwebtoken');
// Secret key used to sign JWTs
const secretKey = 'mySecretKey';
// Function to generate a JWT
function generateToken(user) {
const token = jwt.sign({ id: user.id }, secretKey, { expiresIn: '1h' });
return token;
}
// Function to verify a JWT
function verifyToken(token) {
try {
const decoded = jwt.verify(token, secretKey);
return decoded;
} catch (err) {
throw new Error('Invalid token');
}
}
// Resolver for a protected query
function protectedQuery(_, args, context) {
// Verify the JWT in the request headers
const token = context.headers.authorization.split(' ')[1];
const decodedToken = verifyToken(token);
// Query the data using the user ID in the JWT
const userId = decodedToken.id;
const data = queryDatabase(userId);
return data;
}
// Resolver for a login mutation
function login(_, args) {
// Verify the user's credentials
const user = verifyUser(args.username, args.password);
// Generate a JWT for the user
const token = generateToken(user);
// Return the JWT to the client
return { token };
}

In this example, we define two functions for generating and verifying JWTs: generateToken() and verifyToken(). The generateToken() function takes a user object as input and returns a JWT signed with a secret key. The verifyToken() function takes a token as input and returns the decoded payload if the token is valid, or throws an error if the token is invalid.

We also define two resolvers: protectedQuery() and login(). The protectedQuery() resolver is used to query protected data that requires authentication. It first verifies the JWT in the request headers using the verifyToken() function, and then queries the data using the user ID in the JWT.

The login() resolver is used to authenticate users and generate a JWT for them. It first verifies the user's credentials using a hypothetical verifyUser() function, then generates a JWT using the generateToken() function and returns it to the client.

To use this example in your own GraphQL API, you would need to modify the resolvers to match your API's schema and data sources. You must also configure the GraphQL server to parse and validate JWTs in the request headers.

GraphQL Authorization

Authentication is the process of verifying a user's identity, while authorization is the process of granting access to resources based on the user's identity and the permissions they have. Once a user is authenticated, we need to ensure they have the necessary permissions to access the requested resources.

GraphQL provides a built-in way to implement authorization through directives. Directives are annotations that can be added to the schema definition to provide additional functionality. In this case, we'll use the @auth directive to restrict access to certain fields or types based on the user's permissions.

Let's look at how we can implement authorization in our GraphQL API.

Role-based authorization

A popular method for restricting access to resources in a GraphQL API is role-based authorisation. Each user is given a role under role-based authorisation, which establishes their level of access to resources.

A user with the role of "admin" might have access to all resources, whereas a user with the role of "guest" might only have access to a portion of the resources.

Here how to use the graphql-shield package to establish role-based authorization in a GraphQL API:

const { rule, shield, and, or, not } = require('graphql-shield');
// Define roles
const ADMIN = 'admin';
const USER = 'user';
const GUEST = 'guest';
// Define rules
const isAuthenticated = rule({ cache: 'contextual' })(async (parent, args, ctx, info) => {
// Check if user is authenticated
return ctx.user !== null;
});
const isAdmin = rule({ cache: 'contextual' })(async (parent, args, ctx, info) => {
// Check if user has admin role
return ctx.user.role === ADMIN;
});
const isUser = rule({ cache: 'contextual' })(async (parent, args, ctx, info) => {
// Check if user has user role
return ctx.user.role === USER;
});
const isGuest = rule({ cache: 'contextual' })(async (parent, args, ctx, info) => {
// Check if user has guest role
return ctx.user.role === GUEST;
});
// Define permissions
const permissions = shield({
Query: {
// Require authentication for all queries
'*': isAuthenticated,
// Allow all users to view public resources
publicResource: isGuest,
// Allow all authenticated users to view protected resources
protectedResource: isUser,
// Allow only admin users to view admin resources
adminResource: isAdmin
},
Mutation: {
// Require authentication for all mutations
'*': isAuthenticated,
// Allow all authenticated users to update their own profile
updateProfile: isUser,
// Allow only admin users to create new users
createUser: isAdmin
}
});
// Export permissions middleware
module.exports = permissions;

In this example, we define three roles: admin, user, and guest. We then define four rules using the rule function from graphql-shield. The isAuthenticated rule checks if the user is authenticated, while the isAdmin, isUser, and isGuest rules check if the user has the corresponding role.

We then define permissions using the shield function from graphql-shield. The permissions object specifies which rules apply to each query and mutation. For example, we require authentication for all queries and mutations, and only allow admin users to create new users.

Finally, we export the permissions middleware, which can be used to protect your GraphQL schema. You can apply the permissions middleware to your schema using a middleware library such as express-graphql.

Attribute-based authorization

Attribute-based authorization (ABA) is a type of authorization mechanism that involves making access decisions based on the attributes of the user or client making the request. In GraphQL, ABA can be used to control access to specific fields or types based on the attributes of the requesting user or client.

Here's an example of how ABA can be implemented in a GraphQL API using the graphql-shield library:

const { rule, shield } = require('graphql-shield')
const isAuthenticated = rule({ cache: 'contextual' })(
async (parent, args, ctx, info) => {
return ctx.user !== null
},
)
const isAdmin = rule({ cache: 'contextual' })(
async (parent, args, ctx, info) => {
return ctx.user.role === 'admin'
},
)
const permissions = shield({
Query: {
// Only authenticated users can access the `me` query
me: isAuthenticated,
// Only admin users can access the `users` query
users: isAdmin,
},
Mutation: {
// Only authenticated users can access the `createPost` mutation
createPost: isAuthenticated,
// Only the author of a post can delete it
deletePost: rule({ cache: 'contextual' })(
async (parent, { id }, ctx, info) => {
const post = await getPostById(id)
return post.authorId === ctx.user.id
},
),
},
})

In this example, we're using graphql-shield to define rules that control access to specific queries and mutations in the GraphQL schema. We have two rules defined: isAuthenticated and isAdmin.

The isAuthenticated rule checks whether the user making the request is authenticated. If the user is authenticated, the rule returns true. Otherwise, it returns false. The isAdmin rule checks whether the user making the request has the admin role. If the user has the admin role, the rule returns true. Otherwise, it returns false.

We then use these rules to define the permissions for each query and mutation in the schema. For example, we use the isAuthenticated rule to restrict access to the query and the createPost mutation. We're using the isAdmin rule to restrict access to the users query. We're also using a custom rule to restrict access to the deletePost mutation. This rule checks whether the user making the request is the author of the post being deleted.

Custom authorization

Custom authorization in GraphQL involves implementing custom logic to determine whether a user or client can access a specific resource or perform a specific action. This can involve checking the user's role or permissions, validating input data, or implementing rate limiting to prevent abuse.

Here's an example of how custom authorization can be implemented in a GraphQL resolver:

const resolvers = {
Query: {
mySensitiveData: async (_, __, { user }) => {
if (!user || user.role !== 'admin') {
throw new Error('Unauthorized');
}
// Fetch and return sensitive data
const sensitiveData = await fetchSensitiveData();
return sensitiveData;
},
},
};

In this code, the resolver for the mySensitiveData field checks whether the user is authenticated and has the 'admin' role. If the user is not authenticated or doesn't have the correct role, the resolver throws an error indicating that the user is unauthorized.

Custom authorization can be implemented in a variety of ways, depending on the specific needs of your GraphQL API. For example, you might implement custom logic to check whether a user has permission to update a resource, or to limit the rate at which certain requests can be made.

You can check out this documentation on how to implement authorizations with Hygraph.

Best Practices for Securing a GraphQL API

There are various recommended practices you can adhere to so as to make sure your GraphQL API is secure, in addition to putting authentication and permission systems in place:

  • Encrypt sensitive data: Use encryption to protect sensitive data in transit and at rest.
  • Implement rate limiting: Limit the number of requests that can be made to the API in a given period to prevent abuse.
  • Validate input: Validate input to prevent injection attacks and other security vulnerabilities.
  • Keep the GraphQL schema simple: Limit introspection and expose what is necessary to clients.
  • Regularly audit the API: Perform security audits to identify and address vulnerabilities promptly.

Conclusion

Security is a continuous process; thus, it's crucial to routinely check your GraphQL API for potential flaws and patch them as soon as you find them.

In conclusion, building robust authentication and authorization mechanisms and adhering to security best practices are needed to secure a GraphQL API.

Now that you have a solid understanding of GraphQL authentication and authorization, you can apply these principles to your own API to ensure it's secure and protected.