<p dir="ltr"></p>
<p dir="ltr">-Atin<br>
Sent from one plus one<br>
On 02-Mar-2016 12:23 pm, &quot;Aravinda&quot; &lt;<a href="mailto:avishwan@redhat.com">avishwan@redhat.com</a>&gt; wrote:<br>
&gt;<br>
&gt; Hi,<br>
&gt;<br>
&gt; For Gluster REST project we are planning to use JSON Web Token for<br>
&gt; authentication. There are two approaches to use JWT, please help us to<br>
&gt; evaluate between these two options.<br>
&gt;<br>
&gt; <a href="http://jwt.io/">http://jwt.io/</a><br>
&gt;<br>
&gt; For both approach, user/app will register with Username and Secret.<br>
&gt;<br>
&gt; Shared Token Approach:(Default as per JWT website <a href="http://jwt.io/introduction/">http://jwt.io/introduction/</a>)<br>
&gt; ------------------------------------------------------------------------------<br>
&gt; Server will generate JWT with pre-configured expiry once user login to<br>
&gt; server by providing Username and Secret. Secret is encrypted and<br>
&gt; stored in Server. Clients should include that JWT in all requests.<br>
&gt;<br>
&gt; Advantageous:<br>
&gt; 1. Clients need not worry anything about JWT signing.<br>
&gt; 2. Single secret at server side can be used for all token verification.<br>
&gt; 3. This is a stateless authentication mechanism as the user state is<br>
&gt;    never saved in the server memory(<a href="http://jwt.io/introduction/">http://jwt.io/introduction/</a>)<br>
&gt; 4. Secret is encrypted and stored in Server.<br>
&gt;<br>
&gt; Disadvantageous:<br>
&gt; 1. URL Tampering can be protected only by using HTTPS.<br>
&gt;<br>
&gt; Shared Secret Approach:<br>
&gt; -----------------------<br>
&gt; Secret will not be encrypted in Server side because secret is<br>
&gt; required for JWT signing and verification. Clients will sign every<br>
&gt; request using Secret and send that signature along with the<br>
&gt; request. Server will sign again using the same secret to check the<br>
&gt; signature match.<br>
&gt;<br>
&gt; Advantageous:<br>
&gt; 1. Protection against URL Tampering without HTTPS.<br>
&gt; 2. Different expiry time management based on issued time<br>
&gt;<br>
&gt; Disadvantageous:<br>
&gt; 1. Clients should be aware of JWT and Signing<br>
&gt; 2. Shared secrets will be stored as plain text format in server.<br>
&gt; 3. Every request should lookup for shared secret per user.</p>
<p dir="ltr">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&#39;d really like to see the same technique been used by all of our projects like Heketi, GD2 ReST etc. <br>
&gt;<br>
&gt; -- <br>
&gt; regards<br>
&gt; Aravinda<br>
&gt;<br>
&gt; _______________________________________________<br>
&gt; Gluster-devel mailing list<br>
&gt; <a href="mailto:Gluster-devel@gluster.org">Gluster-devel@gluster.org</a><br>
&gt; <a href="http://www.gluster.org/mailman/listinfo/gluster-devel">http://www.gluster.org/mailman/listinfo/gluster-devel</a><br>
</p>