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

[Aravinda]

Found similarity with OAuth. OAuth 1.0 is Shared secret and OAuth 2.0 is 
shared token.
http://hueniverse.com/2010/05/15/introducing-oauth-2-0/

regards
Aravinda

On 03/02/2016 03:10 PM, Atin Mukherjee wrote:
> -Atin
> Sent from one plus one
> On 02-Mar-2016 12:23 pm, "Aravinda" <avishwan at redhat.com> wrote:
>> 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.
> Although the former looks simple (and may be easy from implementation) the
> later looks more secured. Do you see any major performance bottleneck with
> second one, if not my vote will be for shared secret. However at the same
> point of time I'd really like to see the same technique been used by all of
> our projects like Heketi, GD2 ReST etc.
>> --
>> regards
>> Aravinda
>>
>> _______________________________________________
>> Gluster-devel mailing list
>> Gluster-devel at gluster.org
>> http://www.gluster.org/mailman/listinfo/gluster-devel