Skip to content

docs: add page on authorization strategies #4396

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 7 commits into from
May 28, 2025

Conversation

sarahxsanders
Copy link
Contributor

Adds page on authorization strategies, right after authentication/middleware page

Also adds a "Before you start" section about using ESM syntax JS code snippets

@JoviDeCroock JoviDeCroock merged commit dda8cc2 into graphql:16.x.x May 28, 2025
20 checks passed
Copy link
Member

@benjie benjie left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we will probably need to revisit this guide to align it better with the standard advice we provide to people building GraphQL APIs; currently it conflicts with the main graphql.org documentation on the topic.

@@ -100,3 +100,5 @@ In a REST API, authentication is often handled with a header, that contains an a
If you aren't familiar with any of these authentication mechanisms, we recommend using `express-jwt` because it's simple without sacrificing any future flexibility.

If you've read through the docs linearly to get to this point, congratulations! You now know everything you need to build a practical GraphQL API server.

Want to control access to specific operations or fields? See [Authorization Strategies](\pages\docs\authorization-strategies.mdx).
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is it right that this is using backslashes?

Comment on lines +151 to +152
- Keep authorization logic close to business logic. Resolvers are often the
right place to keep authorization logic.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This does not feel like the right messaging to me; in general we encourage that authorization logic should be inside the business logic, and that resolvers should not be used for authorization. You should be able to expose the same business logic over GraphQL, REST, RPC, or any other API approach without having to re-implement authorization - GraphQL is just a method of access to these underlying methods.

From https://graphql.org/learn/authorization/:

Defining authorization logic inside the resolver is fine when learning GraphQL or prototyping. However, for a production codebase, delegate authorization logic to the business logic layer.

We also highlight this approach in the "thinking in graphs" article:

image

yaacovCR pushed a commit to yaacovCR/graphql-js that referenced this pull request May 30, 2025
Adds page on authorization strategies, right after
authentication/middleware page

Also adds a "Before you start" section about using ESM syntax JS code
snippets

---------

Co-authored-by: Jovi De Croock <[email protected]>
yaacovCR pushed a commit that referenced this pull request May 30, 2025
Adds page on authorization strategies, right after
authentication/middleware page

Also adds a "Before you start" section about using ESM syntax JS code
snippets

---------

Co-authored-by: Jovi De Croock <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants