Gateway level authorization.

[agarwal-nitesh]

For the use case of gateway level authorization, do you recommend a particular graphql query? I was checking getToken in authorizer-js (authorizer-js-code). Would you recommend using it for this use case?

A few more queries: Once a user logs in (authorizer-js-code), we get access_token, id_token and user details in response.
A. What is id_token?
B. Is access_token the authorization code?
C. Are we supposed to use this authorization code to then get the access token?
D. Once we have the access token, what query should we use to protect resources in different services?

[lakhansamani]

@agarwal-nitesh by gateway level authorization, I suppose you mean server side authorization (something like node-js middleware)

I would recommend using id_token in the middleware and just validate that jwt using jwt libraries that are present for the specific lang.

A. Difference between access_token & id_token

• access_token is used to validate if user has access to particular requested date (based on roles, in future we will introduced api based scopes for this)
• id_token is used to get the user information in jwt token
  This is implemented based on OpenID standard: https://openid.net/specs/openid-connect-basic-1_0.html

B. Yes, access_token is authorization code validated against the roles provided.

C. How to get access token

• Access token can be obtained in 2 ways
• 1. If you are using offline scope then you get refresh token in response and using that refresh token you can call getToken to get the new access token & id token. This flow is helpful in case of mobile application as we might not have access to http only cookie there. Usually known as PKCE flow (though more parameters are there for this. To make it simpler we have implemented authorize method.
• 2. If you have http only cookie present, in case of web application. You don't need any code to passed you will get access token in response of getSession / getToken. This is known as implict flow

D. Once you have the access token, you can use getSession but this can rotate your access token for security reasons. I will implement a query for gateway level validation which does not rotate the jwt and you can use it to verify against the roles of the user.

[agarwal-nitesh]

The authorize method can only be called from the browser, I suppose?
Validating with id_token would mean storing it on a user device, browser/mobile, won't it? Also, how do you handle expiry in this case?

[lakhansamani]

True authorize method is for browser.

For validating with id_token you can store it in memory for particular no need to store it in local-storage or session-storage.

Here is how expiry is manged

1. refresh token is long lived token (though rotated with each validation request if used in offline mode. It is also validated on backend as they are persisted in session storage (memory/redis whatever is configured)). Not recommended for browser.
2. access token is short lived token 30 min (this is also rotated with each token / session request. It is also validated on backend as they are persisted in session storage (memory/redis whatever is configured))
3. id_token is also short lived token 30 min (this is not persisted on backend, one can just validated as you validate any other jwt token (issuer, expire time, signing key))

[lakhansamani]

Will add all this information docs as I get more bandwidth :-)

[lakhansamani]

Planning to add new Query which can help in validating all 3 token types, without rotating them so that you can have it synced between frontend and middleware

[agarwal-nitesh]

I was planning on using asymmetric encryption for JWT. Public key encryption and then stored in local storage. This all happens on the client-side and on the API gateway. Do you think this is unnecessary? Is there a slack channel or an irc?

[lakhansamani]

@agarwal-nitesh there is discord server:
https://discord.gg/Zv2D5h6kkK

[lakhansamani]

I was planning on using asymmetric encryption for JWT. Public key encryption and then stored in local storage. This all happens on the client-side and on the API gateway. Do you think this is unnecessary

I agree for this, it can be done in frontend or API gateway.