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

[Aravinda]

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" <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.
>