-
Notifications
You must be signed in to change notification settings - Fork 2k
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
docs: add page on authorization strategies #4396
Conversation
Co-authored-by: Jovi De Croock <[email protected]>
There was a problem hiding this 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). |
There was a problem hiding this comment.
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?
- Keep authorization logic close to business logic. Resolvers are often the | ||
right place to keep authorization logic. |
There was a problem hiding this comment.
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:
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]>
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]>
Adds page on authorization strategies, right after authentication/middleware page
Also adds a "Before you start" section about using ESM syntax JS code snippets