Secure graphql by query

Support
,
1

Hello,

I have an external (.net) graphql api with several queries. I want some query to be public and others to be secure (token, openid …)

How can we configure this in Tyk?

Thank you

2

Hi @nmejane and welcome to the community. I think this thread has similarities to what you are looking for. The definition is there is for a policy but it can also be used for a key.

However, I don’t think the field based access rights or restricted types fits your intended use case.

3

Hey @nmejane,

if I may confirm that I understand the question correctly. I assume you have something like this in your service:

type Query {
  query1: [foo]
  query2: [bar]
  query3: [lalala]
}

And you’d want query1 to be accessible to anyone, public and keyless, and then query2 and query3 to sit behind auth?

4

Hello,

Yes, that’s exactly my question.

Thanks,

5

@Olu started you on the right track there, but all that you want to do will not be possible in one go I’m afraid - not in Tyk, not anywhere else right now I think. Here’s what I would advise:

Option 1:

  • Proxy your GQL service via Tyk and set authentication to what you want (basic auth, JWT, OAuth2, etc)
  • Create a “public” key that will be using field-based permissions and allowing access only to query1. You can publish that key and allow your consumers to use it without having to request it every single time
  • For query2 and query3 create a policy with field-based permissions included in it to control access to your schema. The key will need to be requested by consumers when they will want to use it and you will have control over who can send you which query
  • Creating policies/keys: Authentication & Authorization

Option 2:

  • Expose two instances of your service.
  • One by proxying your GQL through Tyk - use field-based permissions here, apply auth to your graph, have control
  • For the second use Universal Data Graph (UDG) and in the schema of that graph include ONLY the queries/types you want consumers to have unlimited access to. Leave that UDG keyless afterwards, so anyone can access it.
  • Universal Data Graph: GraphQL Datasource
6

Thank you very much for your answer.

Option 1 works very well with authentication by key (basic auth), but can we create a public key for the public query (basic auth) and a bearer (openid) for the secure queries.

Thanks again,

7

I’m afraid that this is not possible. Tyk allows using multiple auth methods on a single API but it works like method1 AND method2, rather than method1 OR method2.

In this case I’d proxy the same GQL service twice via the GW.
For the first I would set the method as basic auth and I would use the field-based permissions to cut off access to everything but the query you want to expose publicly.
For the second one I would use OIDC as auth method and just allow access to everything.

So in case I only want to use the public query I use my basic auth credentials you publish for everyone to use. But when I need to get more I use the second proxy and provide openid credentials and can use everything I want.

But it is a cool use case! Thanks for raising this question. Is this a common thing you do in your GQL workflows? What’s the rationale behind it?

8

Hello, thank you for your answer.

If I understand correctly I have to create 2 different entry points (proxy) (each with their own authentication: one with a key, the other with a token) which point to my graphql backend.

In this case, I am forced to have 2 different paths (one /graphqlopen and the other /graphqlsecure)?

My use case is:
I have a web application (spa) with an angular frontend and a graphql (.net) backend.

My application (angular front) must be able to call graphql queries without authentication (anonymous users), but also when users are connected, it must be able to call graphql with a token (openid AzureB2C).

9

Hi,

yeah, at this stage that’s pretty much what you’d have to do if you want to have different auth methods for queries in the same service.

Thanks for explaining the use case! It’s really interesting and we will definitely look into making this sort of thing possible in the future.