GraphQL support Oathkeeper matches

ORY Oathkeeper
#1

Hi,

I’m reading the documentation and I have to say it is really attractive on the paper to mix Oathkeeper, Keto and Hydra. However, for a personal project, my API is a GraphQL and it seems that the matches offered by Oathkeeper are limited to host, path and query for restful resources. After searching for the keyword in this forum and on the documentation, I couldn’t find any answer.

Is there any plan to match on GraphQL query, mutation and subscription? I guess it would be very interesting to have access to the type of request (query, mutation and subscription), the name of the request and its arguments?

Regards,

1 Like
#2

@GRoguelon Were you able to figure this out? I had the same question on if Oathkeeper could support our GraphQL APIs.

#3

Hey there,
it’s been a while, but yes Oathkeeper does support GraphQL.
You can process GraphQL requests with Oathkeeper.

#4

Hi @vinckr, thank you! Any documentation where it is described?

#5

There is the open issue in github regarding GraphQL support, as I understand from it, the is no GraphQL support yet.

@vinckr can you please share any example for GraphQL matches?

#6

Sorry, can’t help you there. I just read that on the forum, but I was wrong.
So what is stated in the issue is completely right.

oathkeeper isn’t able to analyze graphql queries atm.

Oathkeeper secures different endpoints with different rules, and GraphQL uses just one endpoint

Some more from hackerman on the topic.

slack

" The case for filtering data is really very very difficult. Not allowing access based on REST keywords (path, method, …) is quite easy but it gets much more complex when accessing e.g. collections. Other projects also struggle with this, for example OPA. I think they added capabilities into Rego to output SQL but honestly - who wants to run SQL statements from some remote server and write some logic in Rego to baseically add WHERE owner=... ?
I have thought about this also for a while now and wasn’t able to come up with a good solution. I think Oathkeeper goes a good mile and removes at least some logic from your actual backend code but it simply can’t solve these use cases

I think what oathkeeper is most useful for is to take many types of credentials, do some basic checking, and then forward with e.g. a token that the backend can easily work with. I think it’s a long shot to expect the reverse proxy to completely dis/allow application logic
Another idea I had was to add more capabilities to Oathkeeper - ones where you wouldn’t just authorize incoming request but could actually make outgoing calls to e.g. Google APIs and so on - the credentials would be configured in oathkeeper and all you need is to call google through the reverse proxy - the credentials are appended to the request automatically. I don’t think this will be super helpful for systems that have great SDKs and stuff in place but more for APIs where this is not as easy/transparent. Imagine making e.g. an authenticated request to GitHub’s API! We’re actually thinking along that route for the ory cloud product but haven’t made a decision yet"

1 Like