Thanks. We can use Shared secret if https requirement can be completely avoided. I am not sure how to use same SSL certificates in all the nodes of the Cluster.(REST API server patch set 2 was written based on shared secret method based on custom HMAC signing http://review.gluster.org/#/c/13214/2/in_progress/management_rest_api.md)
Listing the steps involved in each side with both the approaches. (Skipping Register steps since it is common to both) Shared Token: ------------- Client side: 1. Add saved token Authorization header and initiate a REST call. 2. If UnAuthorized, call /token and get access_token again and repeat the step 1 Server side: 1. Verify JWT using the Server's secret. Shared Secret: -------------- Client side: 1. Hash the Method + URL + Params and include in qsh claim of JWT 2. Using shared secret, create JWT. 3. Add previously generated JWT in Authorization header and initiate REST call Server side: 1. Recalculate the hash using same details (Method + URL + Params) and verify with received qsh 2. Do not trust any claims, validate against the values stored in Server(role/group/capabilities) 3. Verify JWT using the shared secret regards Aravinda On 03/03/2016 11:49 AM, Luis Pabon wrote:
Hi Aravinda, Very good summary. I would like to rephrase a few parts. On the shared token approach, the disadvantage is that the server will be more complicated (not *really* complicated, just more than the shared token), because it would need a login mechanism. Server would have to both authenticate and authorize the user. Once this has occurred a token with an expiration date can be handed back to the caller. On the shared secret approach, I do not consider the client creating a JWT a disadvantage (unless you are doing it in C), it is pretty trivial for programs written in Python, Go, Javascript etc to create a JWT on each call. - Luis ----- Original Message ----- From: "Aravinda" <avish...@redhat.com> To: "Gluster Devel" <gluster-devel@gluster.org> Cc: "Kaushal Madappa" <kmada...@redhat.com>, "Atin Mukherjee" <amukh...@redhat.com>, "Luis Pabon" <lpa...@redhat.com>, kmayi...@redhat.com, "Prashanth Pai" <p...@redhat.com> Sent: Wednesday, March 2, 2016 1:53:00 AM Subject: REST API authentication: JWT - Shared Token vs Shared Secret Hi, For Gluster REST project we are planning to use JSON Web Token for authentication. There are two approaches to use JWT, please help us to evaluate between these two options. http://jwt.io/ For both approach, user/app will register with Username and Secret. Shared Token Approach:(Default as per JWT website http://jwt.io/introduction/) ------------------------------------------------------------------------------ Server will generate JWT with pre-configured expiry once user login to server by providing Username and Secret. Secret is encrypted and stored in Server. Clients should include that JWT in all requests. Advantageous: 1. Clients need not worry anything about JWT signing. 2. Single secret at server side can be used for all token verification. 3. This is a stateless authentication mechanism as the user state is never saved in the server memory(http://jwt.io/introduction/) 4. Secret is encrypted and stored in Server. Disadvantageous: 1. URL Tampering can be protected only by using HTTPS. Shared Secret Approach: ----------------------- Secret will not be encrypted in Server side because secret is required for JWT signing and verification. Clients will sign every request using Secret and send that signature along with the request. Server will sign again using the same secret to check the signature match. Advantageous: 1. Protection against URL Tampering without HTTPS. 2. Different expiry time management based on issued time Disadvantageous: 1. Clients should be aware of JWT and Signing 2. Shared secrets will be stored as plain text format in server. 3. Every request should lookup for shared secret per user.
_______________________________________________ Gluster-devel mailing list Gluster-devel@gluster.org http://www.gluster.org/mailman/listinfo/gluster-devel
