On Thu, Mar 3, 2016 at 2:39 PM, Aravinda <avishwan@xxxxxxxxxx> wrote: > 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. You forgot the part where server generates the token. :) > > > 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 > Anyways, I'm still not sure which of the two approaches I like better. My google research on this topic (ReST api authentication) led to many results which followed a token approach. This causes me to lean slightly towards shared tokens. Since, I can't decide, I plan to write down workflows involved for both and try to compare them that way. It would probably help arrive at a decision. I'll try to share this ASAP (probably this weekend). > 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" <avishwan@xxxxxxxxxx> >> To: "Gluster Devel" <gluster-devel@xxxxxxxxxxx> >> Cc: "Kaushal Madappa" <kmadappa@xxxxxxxxxx>, "Atin Mukherjee" >> <amukherj@xxxxxxxxxx>, "Luis Pabon" <lpabon@xxxxxxxxxx>, >> kmayilsa@xxxxxxxxxx, "Prashanth Pai" <ppai@xxxxxxxxxx> >> 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@xxxxxxxxxxx > http://www.gluster.org/mailman/listinfo/gluster-devel _______________________________________________ Gluster-devel mailing list Gluster-devel@xxxxxxxxxxx http://www.gluster.org/mailman/listinfo/gluster-devel
