[Gluster-devel] REST API authentication: JWT - Shared Token vs Shared Secret

[Kaushal M]

On Thu, Mar 3, 2016 at 2:39 PM, Aravinda <avishwan at redhat.com> 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 at redhat.com>
>> To: "Gluster Devel" <gluster-devel at gluster.org>
>> Cc: "Kaushal Madappa" <kmadappa at redhat.com>, "Atin Mukherjee"
>> <amukherj at redhat.com>, "Luis Pabon" <lpabon at redhat.com>,
>> kmayilsa at redhat.com, "Prashanth Pai" <ppai at 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 at gluster.org
> http://www.gluster.org/mailman/listinfo/gluster-devel