@auth - JWT in JWE format - can dgraph handle it?

Issues Dgraph
, , , ,
#1

So I am exploring the so called “poor man’s auth” options with JWTs, and I realized that JWTs (in the JWS format) are decodable without any secret.

So my question is:
If I want to encrypt the “claims” of my auth tokens, can Dgraph handle that?

If not, can we refine this issue into a feature request?

If so, how?

  • How does one setup the keys?
    • which keys need to be used for encrypting/decrypting signing/verifying ?
#2

@pawan any ideas? Specifically on encrypting claims

@gotjoshua if you want, I suspect Sam Julien will have something on that in his talk for the GraphQL in Space conference tomorrow. Check it out: https://www.graphqlcon.space/

#3

I always look at JWT as being an identity token that can only be used if it is verified. I don’t keep any kind of password or even email address in the any client side JWT just only as much as I need to link to which identity has been authenticated so I can use it to authorize the correct information. So what if someone gets a JWT and decodes it, they can not modify it and send it back because then it will not be verified. The secret is the private key. Keep that more secure than Ft. Knox

#4

Hey @amaster507, well… yeah, i’d say should only be used if its verified, but unfortunately it can be decoded and used without being altered by pretty much any code that gets its paws on it.

As I understand there is no way to really tie a User session to an IP address and have a JWT that is only verified for that user from that IP for the duration of that session.

Maybe I am over thinking this… (or being a bit over-cautious)
… but as I understand it:
If my server (or auth0 as Dgraph uses in the examples) sends a JWT to the client, and then the client uses that JWT to gain access to Dgraph, any other client from any other IP would be able to use that same JWT to access everything that the original client has access to.
Is that true?

The JWT is still signed by the same private key, and still “valid” no matter where it is reused from.
Therefore we are depending only on https security to guard the JWT in transit and depending on browser javascript security as long as the JWT is in memory.

#5

@pawan and @chewxy … looking forward to your replies

I signed up for the conf and i see the talk that you refer to… hopefully I’ll have time to join.

#6

After more thinking, I am considering a strategy like this:

My backed component:

  1. gets a valid Oauth token for a user
  2. creates a JWE that includes claims:
{ 
ip: x.x.x.x,
userID: ###,
sessionID: ###
}  // this payload would be signed and encrypted with a key 
// that only dgraph and the backend know

  1. the backend needs to update the user->sessionID edge with a facet for the (ip=x.x.x.x)

  2. this JWE can be stored by the client and used to authenticate queries and mutations
    via dgraph-js-http and the @auth rules need to do the sessionID and ip matching

In order for all this to work, Dgraph @auth would need to be able to handle decrypting the JWE payload

Sam Julien - Becoming a “Secret” Agent: Securing Your GraphQL Backend with JWTs
#7

Things to consider…

  • Users behind load balancers that switch IPs between requests.
  • Mobile users as they travel and use different WANs and networks.
  • A user being signed in from multiple devices.
1 Like
#8

ooo, good call. maybe IP isn’t a good idea at all.

Perhaps a session array would be better:

userUID <Sessions> _:session1UID  
_:session1UID <SessionSecret>  string
_:session1UID <Expires>  date

userUID <Sessions> _:session2UID
_:session2UID <SessionSecret> ...
#10

Definitely adding support for JWE will be beneficial as we won’t be able to decrypt the payload without the key. Using JWT variables and @auth rules you will be able to achieve some form of authorization based on IP/Session ID.
I explored our current code and it seems that the library we use for JWT doesn’t support JWE.

But there is another library that supports JWE. Probably we can explore it and use the same. Accepting this issue and we will update you once we start working on it.

1 Like