Fork me on GitHub
#graphql
<
2020-05-28
>
fabrao02:05:22

hello all, how do you deal with authentication ?

fabrao02:05:06

I thought using a mutation login that after check user and password return a token that will pass in all queries. Is that a good way to do this?

Lennart Buit05:05:54

We just pass an Authentication header, with a JWT that you got from an oauth provider

oliy06:05:16

You can pass a connection-init-payload with Apollo or re-graph, and lacinia-pedestal can handle it

defa07:05:55

I use https://www.keycloak.org as an external OAuth 2 provider and have an interceptor attached to verify this token. Works fine.

defa07:05:22

… now I’m trying to use GraphQL directives implement role based access controls on resolvers and I’m struggling with finding the right place to put my interceptor…

fabrao13:05:35

Lennart have you used lacinia?

Lennart Buit19:05:18

We basically have a little interceptor in our stack that checks you have a valid access token (JWT in our case). So thats prior to lacinia getting involved.

Lennart Buit19:05:52

And our clients send it with the Authorization HTTP header using the Bearer schema

defa07:05:12

Regarding https://lacinia.readthedocs.io/en/latest/directives.html… I use JWT for login/access control and in the token’s claims there are the roles assigned to the user. I used GraphQL directives to attach roles to queries and mutations and I’d like to check them before executing the resolver. Within the resolver I can access the directive defined in the schema:

(->> context
     :com.walmartlabs.lacinia/selection
     :field-definition
     :directives
     (filter #(= :access (:directive-type %)))
     first
     :directive-args
     :roles)
In the schema the directive is defined like this:
:directives [{:directive-type :access
              :directive-args {:roles ["admin"]}
and I can check against the claims I’m extracting from the JWT token using a custom interceptor. Now I’m struggling to find the right place to inject an interceptor that checks the roles from the JWT token claims against the access-roles defined in the schema (query directive). The thing is, that he context in none of the places I tried to inject my interceptor has the :com.walmartlabs.lacinia/selection key. Any ideas? … after digging around and thinking a little, I guess I’ll go with wrapping all resolvers before passing them to com.walmartlabs.lacinia.util/attach-resolvers . Any better ideas?

hlship16:05:46

Feels like this needs a Lacinia enhancement; selections-seq2 could expose field-level directives.