Moved from GitHub dgraph/5173
Posted by emregency:
Note: Feature requests are judged based on user experience and modeled on Go Experience Reports. These reports should focus on the problems: they should not focus on and need not propose solutions.
What you wanted to do
I wanted to evaluate the Enterpise License to know if I can authenticate users using JWT tokens issued by an IAM provider.
What you actually did
I went to check the documentation to see if this was possible. I discovered that dGraph was actually also acting as an IAM service, partially.
The secret key is used by Alpha servers to sign JSON Web Tokens (JWT). As you’ve probably guessed, it’s critical to keep the secret key as a secret. Another requirement for the secret key is that it must have at least 256-bits, i.e. 32 ASCII characters, as we are using HMAC-SHA256 as the signing algorithm.
Why that wasn’t great, with examples
It wasn’t great because, if I think of a dB, I think of it as a data service in my application in harmony with the other services. As users need to consume different services within the context of an application, I was considering to implement
defense-in-depth using the enterprise edition of dGraph service. I was considering if dGraph can authenticate a user through a JWT, then apply ACL based on that.
1- User identifies through a UI with PKCE to an IAM service
2- IAM service authenticates the User and returns a JWT
3- UI sends a request to the API Gateway with the Bearer authorization header
4- API Gateway validates the JWT and authorizes the user for services or operations
5- API Gateway relays the request to the relevant service with the User JWT
6- Every service checks again ACL based on User JWT
Graph ACL #5167 + User JWT = defense-in-depth, unified accountability across services, reduced attack surface for lateral movement and information disclosure.