You are viewing a plain text version of this content. The canonical link for it is here.
Posted to custos@airavata.apache.org by Suresh Marru <sm...@apache.org> on 2020/07/08 01:32:15 UTC
Re: [Discussion] Securing single-page-application using JWT token
Thanks Anuj for your insights.
Hi Isuru,
It might help draw up an architecture of front end UI components to backend security gateway to brainstorm this and arrive at a consensus of handling API security for UI’s.
Suresh
> On Jul 7, 2020, at 7:52 PM, anuj bhandar <bh...@gmail.com> wrote:
>
> I agree with your research, Options [1] & [2] are not recommended.
>
> We use AWS Amplify (https://aws.amazon.com/amplify/ <https://aws.amazon.com/amplify/>) to handle that scenario, our tech stack comprises React front-end, AWS Amplify integrated with our company's SSO provider, and an Rails API backend.
>
> Using a third party like AWS Amplify will not handle all the security concerns, you will have to pay special attention to Token Validity. JWT claims offer a good amount of control if set up properly (https://tools.ietf.org/html/rfc7519 <https://tools.ietf.org/html/rfc7519>).
>
> I am not sure if this was helpful. Happy to help wherever I can.
>
> Thanks,
> Anuj Bhandar
> Intuit Inc.
>
> On Tue, Jul 7, 2020 at 3:52 PM Rastogi, Shivam <srastog@iu.edu <ma...@iu.edu>> wrote:
> Hi Everyone,
>
>
>
> Just wanted to check if anyone has any experience in securing Single Page Webapps using JWT tokens.
>
>
>
>
> Challenge
>
> The challenge we are facing is how to store the JWT token at the client-side in the browser which will be used to securely call the back-end APIs.
>
>
>
> Background
>
> We are working on the custos UI portal and one of the design options that we are considering is to directly call the custos backend APIs from client-side javascript. The basic flow would look like:
>
>
>
> 1. User logins using username and password from the login screen using login API
>
> 2. JWT token and basic user-information is returned to the client in response.
>
> 3. In subsequent API requests, user will send this authentication token. But,how to store this token at client-side?
>
>
>
> Options
>
> Store it in localStorage - This is not considered to be secure as localstorage is vulnerable to XSS attacks-
> https://dev.to/rdegges/please-stop-using-local-storage-1i04 <https://dev.to/rdegges/please-stop-using-local-storage-1i04> -
> Store the JWT token in httpOnly cookie - Browser adds the cookie to all the API calls - vulnerable to CSRF attacks and need to be protected using CSRF token or in some other manner. Do you have any experience implementing these securely?
> Have an authentication middleware(API gateway) - All user requests are routed to API-gateway which authenticates the users using sessionId and then re-routes the requests to the API by including the users JWT token or session information. More of a traditional way of doing things, but some big companies use this approach like Airbnb as per this article - https://medium.com/airbnb-engineering/building-services-at-airbnb-part-2-142be1c5d506 <https://medium.com/airbnb-engineering/building-services-at-airbnb-part-2-142be1c5d506>
>
>
> It would be really helpful if you can provide any inputs or share your experience with SPAs.
>
>
>
> Thanks and regards,
>
> Shivam Rastogi
>
Re: [Discussion] Securing single-page-application using JWT token
Posted by "Christie, Marcus Aaron" <ma...@iu.edu>.
It might be worth looking at Keycloak's JS client adapter to see how they handle some of these things: https://www.keycloak.org/docs/latest/securing_apps/index.html#_javascript_adapter <https://www.keycloak.org/docs/latest/securing_apps/index.html#_javascript_adapter>
> On Jul 8, 2020, at 4:55 PM, Isuru Ranawaka <ir...@gmail.com> wrote:
>
> We need to finalize methods to store access token, refresh token and Id
> token. As Shivam , anuj suggested can use local storage, cookies or API
> Gateway approach. Any ideas on
> - How to handle silent refresh for invalidated tokens
The Keycloak adapter has an updateToken() function that refreshes only if needed and returns a promise in which you're guaranteed a valid token. https://www.keycloak.org/docs/latest/securing_apps/index.html#updatetoken-minvalidity <https://www.keycloak.org/docs/latest/securing_apps/index.html#updatetoken-minvalidity>
> - Synchronizing logouts for multiple tabs
See the Session Status iframe: https://www.keycloak.org/docs/latest/securing_apps/index.html#session-status-iframe <https://www.keycloak.org/docs/latest/securing_apps/index.html#session-status-iframe>
>>>
> I guess httpOnly cookie is added from the server-side. But that won't be
> feasible with the current approach. Custos provides access tokens in the
> body, and not capable of handling cookies. I guess we can achieve this via
> intermediate proxy. any thoughts?
Is this a grpc-web limitation? Also, I'm guessing you'll need a proxy or something to read the access token out of the cookie on the server-side.
Re: [Discussion] Securing single-page-application using JWT token
Posted by Isuru Ranawaka <ir...@gmail.com>.
Hi Suresh,
please find the inline URL
On Wed, Jul 8, 2020 at 5:02 PM Suresh Marru <sm...@apache.org> wrote:
> Hi Isuru,
>
> The images got dropped, can you please add them to wiki and share a link?
>
> Thanks,
> Suresh
>
> > On Jul 8, 2020, at 4:55 PM, Isuru Ranawaka <ir...@gmail.com> wrote:
> >
> > Hi Shivam, Anuj
> >
> > thanks for your comments on this. Please find and below description and
> > comments, it might helpful for further understanding of the message flow
> of
> > authentication and come up with a good design.
>
https://cwiki.apache.org/confluence/display/CUSTOS/Custos+API+Access+and+Frontend+Integration?preview=/158866819/158866820/Custos%20Portal%20Diagram.png
> >
> > The first figure depicts endpoint types for external applications to
> > integrate with Custos services. Non browser applications can directly
> > integrate with Custos using Python, Java, or Rest endpoints as preferred.
> >
> > Integrating browser applications is not straightforward with python SDK
> or
> > JAVA SDK, because it might require some framework to cross the bridge
> > between frontend client side code to server side code. (e.g Django
> > framework). But, browser apps can directly use Rest endpoints for
> > integration.
> >
> > *How Authentication Works*
> >
> > All clients are confidential clients for Custos. The minimum
> > authentication mechanism for APIs is to use basic auth with base64
> encoded
> > Custos credentials. Application should securely store Custos secret and
> use
> > that for basic authentication. Since, this is static, I guess storing
> that
> > won’t be an issue.
> >
> > Some Custos APIs and application APIs require user access tokens to
> > authenticate.
> >
> > At first login, Access token , ID token and Refresh token are issued in
> the
> > response body in JWT. Subsequent calls to API require an access token of
> > the logged user to authenticate.
> >
> > We need to finalize methods to store access token, refresh token and Id
> > token. As Shivam , anuj suggested can use local storage, cookies or
> API
> > Gateway approach. Any ideas on
> > - How to handle silent refresh for invalidated tokens
> > - Synchronizing logouts for multiple tabs
> >
> > On Tue, Jul 7, 2020 at 9:32 PM Suresh Marru <smarru@apache.org <mailto:
> smarru@apache.org>> wrote:
> >
> >> Thanks Anuj for your insights.
> >>
> >> Hi Isuru,
> >>
> >> It might help draw up an architecture of front end UI components to
> >> backend security gateway to brainstorm this and arrive at a consensus of
> >> handling API security for UI’s.
> >>
> >> Suresh
> >>
> >> On Jul 7, 2020, at 7:52 PM, anuj bhandar <bh...@gmail.com>
> wrote:
> >>
> >> I agree with your research, Options [1] & [2] are *not* recommended.
> >>
> >> We use AWS Amplify (https://aws.amazon.com/amplify/) to handle that
> >> scenario, our tech stack comprises React front-end, AWS Amplify
> integrated
> >> with our company's SSO provider, and an Rails API backend.
> >>
> >> Using a third party like AWS Amplify will not handle all the security
> >> concerns, you will have to pay special attention to Token Validity. JWT
> >> claims offer a good amount of control if set up properly (
> >> https://tools.ietf.org/html/rfc7519).
> >>
> >> I am not sure if this was helpful. Happy to help wherever I can.
> >>
> >> Thanks,
> >> *Anuj Bhandar*
> >> Intuit Inc.
> >>
> >> On Tue, Jul 7, 2020 at 3:52 PM Rastogi, Shivam <sr...@iu.edu> wrote:
> >>
> >>> Hi Everyone,
> >>>
> >>>
> >>> Just wanted to check if anyone has any experience in securing Single
> Page
> >>> Webapps using JWT tokens.
> >>>
> >>>
> >>>
> >>> *Challenge*
> >>>
> >>> The challenge we are facing is how to store the JWT token at the
> >>> client-side in the browser which will be used to securely call the
> back-end
> >>> APIs.
> >>>
> >>>
> >>> *Background*
> >>>
> >>> We are working on the custos UI portal and one of the design options
> that
> >>> we are considering is to directly call the custos backend APIs from
> >>> client-side javascript. The basic flow would look like:
> >>>
> >>>
> >>> 1. User logins using username and password from the login screen using
> >>> login API
> >>>
> >>> 2. JWT token and basic user-information is returned to the client in
> >>> response.
> >>>
> >>> 3. In subsequent API requests, user will send this authentication
> token.
> >>> But,how to store this token at client-side?
> >>>
> >>>
> >>> *Options*
> >>>
> >>> 1. *Store it in localStorage* - This is not considered to be secure
> >>> as localstorage is vulnerable to XSS attacks-
> >>> https://dev.to/rdegges/please-stop-using-local-storage-1i04 <
> https://dev.to/rdegges/please-stop-using-local-storage-1i04> -
> >>> 2. *Store the JWT token in httpOnly cookie -* Browser adds the cookie
> >>> to all the API calls - vulnerable to CSRF attacks and need to be
> protected
> >>> using CSRF token or in some other manner. Do you have any experience
> >>> implementing these securely?
> >>>
> >>>
> > I guess httpOnly cookie is added from the server-side. But that won't be
> > feasible with the current approach. Custos provides access tokens in the
> > body, and not capable of handling cookies. I guess we can achieve this
> via
> > intermediate proxy. any thoughts?
> >
> >
> >>> 1.
> >>> 2. *Have an authentication middleware(API gateway) -* All user
> >>> requests are routed to API-gateway which authenticates the users
> using
> >>> sessionId and then re-routes the requests to the API by including
> the users
> >>> JWT token or session information. More of a traditional way of doing
> >>> things, but some big companies use this approach like Airbnb as per
> this
> >>> article -
> >>>
> https://medium.com/airbnb-engineering/building-services-at-airbnb-part-2-142be1c5d506
> >>>
> >>>
> >>>
> >>> It would be really helpful if you can provide any inputs or share your
> >>> experience with SPAs.
> >>>
> >>>
> >>> Thanks and regards,
> >>>
> >>> Shivam Rastogi
> >>>
> >>
> >>
> >
> > --
> > Research Software Engineer
> > Indiana University, IN
>
>
--
Research Software Engineer
Indiana University, IN
Re: [Discussion] Securing single-page-application using JWT token
Posted by Isuru Ranawaka <ir...@gmail.com>.
Hi Suresh,
please find the inline URL
On Wed, Jul 8, 2020 at 5:02 PM Suresh Marru <sm...@apache.org> wrote:
> Hi Isuru,
>
> The images got dropped, can you please add them to wiki and share a link?
>
> Thanks,
> Suresh
>
> > On Jul 8, 2020, at 4:55 PM, Isuru Ranawaka <ir...@gmail.com> wrote:
> >
> > Hi Shivam, Anuj
> >
> > thanks for your comments on this. Please find and below description and
> > comments, it might helpful for further understanding of the message flow
> of
> > authentication and come up with a good design.
>
https://cwiki.apache.org/confluence/display/CUSTOS/Custos+API+Access+and+Frontend+Integration?preview=/158866819/158866820/Custos%20Portal%20Diagram.png
> >
> > The first figure depicts endpoint types for external applications to
> > integrate with Custos services. Non browser applications can directly
> > integrate with Custos using Python, Java, or Rest endpoints as preferred.
> >
> > Integrating browser applications is not straightforward with python SDK
> or
> > JAVA SDK, because it might require some framework to cross the bridge
> > between frontend client side code to server side code. (e.g Django
> > framework). But, browser apps can directly use Rest endpoints for
> > integration.
> >
> > *How Authentication Works*
> >
> > All clients are confidential clients for Custos. The minimum
> > authentication mechanism for APIs is to use basic auth with base64
> encoded
> > Custos credentials. Application should securely store Custos secret and
> use
> > that for basic authentication. Since, this is static, I guess storing
> that
> > won’t be an issue.
> >
> > Some Custos APIs and application APIs require user access tokens to
> > authenticate.
> >
> > At first login, Access token , ID token and Refresh token are issued in
> the
> > response body in JWT. Subsequent calls to API require an access token of
> > the logged user to authenticate.
> >
> > We need to finalize methods to store access token, refresh token and Id
> > token. As Shivam , anuj suggested can use local storage, cookies or
> API
> > Gateway approach. Any ideas on
> > - How to handle silent refresh for invalidated tokens
> > - Synchronizing logouts for multiple tabs
> >
> > On Tue, Jul 7, 2020 at 9:32 PM Suresh Marru <smarru@apache.org <mailto:
> smarru@apache.org>> wrote:
> >
> >> Thanks Anuj for your insights.
> >>
> >> Hi Isuru,
> >>
> >> It might help draw up an architecture of front end UI components to
> >> backend security gateway to brainstorm this and arrive at a consensus of
> >> handling API security for UI’s.
> >>
> >> Suresh
> >>
> >> On Jul 7, 2020, at 7:52 PM, anuj bhandar <bh...@gmail.com>
> wrote:
> >>
> >> I agree with your research, Options [1] & [2] are *not* recommended.
> >>
> >> We use AWS Amplify (https://aws.amazon.com/amplify/) to handle that
> >> scenario, our tech stack comprises React front-end, AWS Amplify
> integrated
> >> with our company's SSO provider, and an Rails API backend.
> >>
> >> Using a third party like AWS Amplify will not handle all the security
> >> concerns, you will have to pay special attention to Token Validity. JWT
> >> claims offer a good amount of control if set up properly (
> >> https://tools.ietf.org/html/rfc7519).
> >>
> >> I am not sure if this was helpful. Happy to help wherever I can.
> >>
> >> Thanks,
> >> *Anuj Bhandar*
> >> Intuit Inc.
> >>
> >> On Tue, Jul 7, 2020 at 3:52 PM Rastogi, Shivam <sr...@iu.edu> wrote:
> >>
> >>> Hi Everyone,
> >>>
> >>>
> >>> Just wanted to check if anyone has any experience in securing Single
> Page
> >>> Webapps using JWT tokens.
> >>>
> >>>
> >>>
> >>> *Challenge*
> >>>
> >>> The challenge we are facing is how to store the JWT token at the
> >>> client-side in the browser which will be used to securely call the
> back-end
> >>> APIs.
> >>>
> >>>
> >>> *Background*
> >>>
> >>> We are working on the custos UI portal and one of the design options
> that
> >>> we are considering is to directly call the custos backend APIs from
> >>> client-side javascript. The basic flow would look like:
> >>>
> >>>
> >>> 1. User logins using username and password from the login screen using
> >>> login API
> >>>
> >>> 2. JWT token and basic user-information is returned to the client in
> >>> response.
> >>>
> >>> 3. In subsequent API requests, user will send this authentication
> token.
> >>> But,how to store this token at client-side?
> >>>
> >>>
> >>> *Options*
> >>>
> >>> 1. *Store it in localStorage* - This is not considered to be secure
> >>> as localstorage is vulnerable to XSS attacks-
> >>> https://dev.to/rdegges/please-stop-using-local-storage-1i04 <
> https://dev.to/rdegges/please-stop-using-local-storage-1i04> -
> >>> 2. *Store the JWT token in httpOnly cookie -* Browser adds the cookie
> >>> to all the API calls - vulnerable to CSRF attacks and need to be
> protected
> >>> using CSRF token or in some other manner. Do you have any experience
> >>> implementing these securely?
> >>>
> >>>
> > I guess httpOnly cookie is added from the server-side. But that won't be
> > feasible with the current approach. Custos provides access tokens in the
> > body, and not capable of handling cookies. I guess we can achieve this
> via
> > intermediate proxy. any thoughts?
> >
> >
> >>> 1.
> >>> 2. *Have an authentication middleware(API gateway) -* All user
> >>> requests are routed to API-gateway which authenticates the users
> using
> >>> sessionId and then re-routes the requests to the API by including
> the users
> >>> JWT token or session information. More of a traditional way of doing
> >>> things, but some big companies use this approach like Airbnb as per
> this
> >>> article -
> >>>
> https://medium.com/airbnb-engineering/building-services-at-airbnb-part-2-142be1c5d506
> >>>
> >>>
> >>>
> >>> It would be really helpful if you can provide any inputs or share your
> >>> experience with SPAs.
> >>>
> >>>
> >>> Thanks and regards,
> >>>
> >>> Shivam Rastogi
> >>>
> >>
> >>
> >
> > --
> > Research Software Engineer
> > Indiana University, IN
>
>
--
Research Software Engineer
Indiana University, IN
Re: [Discussion] Securing single-page-application using JWT token
Posted by Suresh Marru <sm...@apache.org>.
Hi Isuru,
The images got dropped, can you please add them to wiki and share a link?
Thanks,
Suresh
> On Jul 8, 2020, at 4:55 PM, Isuru Ranawaka <ir...@gmail.com> wrote:
>
> Hi Shivam, Anuj
>
> thanks for your comments on this. Please find and below description and
> comments, it might helpful for further understanding of the message flow of
> authentication and come up with a good design.
>
>
> The first figure depicts endpoint types for external applications to
> integrate with Custos services. Non browser applications can directly
> integrate with Custos using Python, Java, or Rest endpoints as preferred.
>
> Integrating browser applications is not straightforward with python SDK or
> JAVA SDK, because it might require some framework to cross the bridge
> between frontend client side code to server side code. (e.g Django
> framework). But, browser apps can directly use Rest endpoints for
> integration.
>
> *How Authentication Works*
>
> All clients are confidential clients for Custos. The minimum
> authentication mechanism for APIs is to use basic auth with base64 encoded
> Custos credentials. Application should securely store Custos secret and use
> that for basic authentication. Since, this is static, I guess storing that
> won’t be an issue.
>
> Some Custos APIs and application APIs require user access tokens to
> authenticate.
>
> At first login, Access token , ID token and Refresh token are issued in the
> response body in JWT. Subsequent calls to API require an access token of
> the logged user to authenticate.
>
> We need to finalize methods to store access token, refresh token and Id
> token. As Shivam , anuj suggested can use local storage, cookies or API
> Gateway approach. Any ideas on
> - How to handle silent refresh for invalidated tokens
> - Synchronizing logouts for multiple tabs
>
> On Tue, Jul 7, 2020 at 9:32 PM Suresh Marru <smarru@apache.org <ma...@apache.org>> wrote:
>
>> Thanks Anuj for your insights.
>>
>> Hi Isuru,
>>
>> It might help draw up an architecture of front end UI components to
>> backend security gateway to brainstorm this and arrive at a consensus of
>> handling API security for UI’s.
>>
>> Suresh
>>
>> On Jul 7, 2020, at 7:52 PM, anuj bhandar <bh...@gmail.com> wrote:
>>
>> I agree with your research, Options [1] & [2] are *not* recommended.
>>
>> We use AWS Amplify (https://aws.amazon.com/amplify/) to handle that
>> scenario, our tech stack comprises React front-end, AWS Amplify integrated
>> with our company's SSO provider, and an Rails API backend.
>>
>> Using a third party like AWS Amplify will not handle all the security
>> concerns, you will have to pay special attention to Token Validity. JWT
>> claims offer a good amount of control if set up properly (
>> https://tools.ietf.org/html/rfc7519).
>>
>> I am not sure if this was helpful. Happy to help wherever I can.
>>
>> Thanks,
>> *Anuj Bhandar*
>> Intuit Inc.
>>
>> On Tue, Jul 7, 2020 at 3:52 PM Rastogi, Shivam <sr...@iu.edu> wrote:
>>
>>> Hi Everyone,
>>>
>>>
>>> Just wanted to check if anyone has any experience in securing Single Page
>>> Webapps using JWT tokens.
>>>
>>>
>>>
>>> *Challenge*
>>>
>>> The challenge we are facing is how to store the JWT token at the
>>> client-side in the browser which will be used to securely call the back-end
>>> APIs.
>>>
>>>
>>> *Background*
>>>
>>> We are working on the custos UI portal and one of the design options that
>>> we are considering is to directly call the custos backend APIs from
>>> client-side javascript. The basic flow would look like:
>>>
>>>
>>> 1. User logins using username and password from the login screen using
>>> login API
>>>
>>> 2. JWT token and basic user-information is returned to the client in
>>> response.
>>>
>>> 3. In subsequent API requests, user will send this authentication token.
>>> But,how to store this token at client-side?
>>>
>>>
>>> *Options*
>>>
>>> 1. *Store it in localStorage* - This is not considered to be secure
>>> as localstorage is vulnerable to XSS attacks-
>>> https://dev.to/rdegges/please-stop-using-local-storage-1i04 <https://dev.to/rdegges/please-stop-using-local-storage-1i04> -
>>> 2. *Store the JWT token in httpOnly cookie -* Browser adds the cookie
>>> to all the API calls - vulnerable to CSRF attacks and need to be protected
>>> using CSRF token or in some other manner. Do you have any experience
>>> implementing these securely?
>>>
>>>
> I guess httpOnly cookie is added from the server-side. But that won't be
> feasible with the current approach. Custos provides access tokens in the
> body, and not capable of handling cookies. I guess we can achieve this via
> intermediate proxy. any thoughts?
>
>
>>> 1.
>>> 2. *Have an authentication middleware(API gateway) -* All user
>>> requests are routed to API-gateway which authenticates the users using
>>> sessionId and then re-routes the requests to the API by including the users
>>> JWT token or session information. More of a traditional way of doing
>>> things, but some big companies use this approach like Airbnb as per this
>>> article -
>>> https://medium.com/airbnb-engineering/building-services-at-airbnb-part-2-142be1c5d506
>>>
>>>
>>>
>>> It would be really helpful if you can provide any inputs or share your
>>> experience with SPAs.
>>>
>>>
>>> Thanks and regards,
>>>
>>> Shivam Rastogi
>>>
>>
>>
>
> --
> Research Software Engineer
> Indiana University, IN
Re: [Discussion] Securing single-page-application using JWT token
Posted by "Christie, Marcus Aaron" <ma...@iu.edu>.
It might be worth looking at Keycloak's JS client adapter to see how they handle some of these things: https://www.keycloak.org/docs/latest/securing_apps/index.html#_javascript_adapter <https://www.keycloak.org/docs/latest/securing_apps/index.html#_javascript_adapter>
> On Jul 8, 2020, at 4:55 PM, Isuru Ranawaka <ir...@gmail.com> wrote:
>
> We need to finalize methods to store access token, refresh token and Id
> token. As Shivam , anuj suggested can use local storage, cookies or API
> Gateway approach. Any ideas on
> - How to handle silent refresh for invalidated tokens
The Keycloak adapter has an updateToken() function that refreshes only if needed and returns a promise in which you're guaranteed a valid token. https://www.keycloak.org/docs/latest/securing_apps/index.html#updatetoken-minvalidity <https://www.keycloak.org/docs/latest/securing_apps/index.html#updatetoken-minvalidity>
> - Synchronizing logouts for multiple tabs
See the Session Status iframe: https://www.keycloak.org/docs/latest/securing_apps/index.html#session-status-iframe <https://www.keycloak.org/docs/latest/securing_apps/index.html#session-status-iframe>
>>>
> I guess httpOnly cookie is added from the server-side. But that won't be
> feasible with the current approach. Custos provides access tokens in the
> body, and not capable of handling cookies. I guess we can achieve this via
> intermediate proxy. any thoughts?
Is this a grpc-web limitation? Also, I'm guessing you'll need a proxy or something to read the access token out of the cookie on the server-side.
Re: [Discussion] Securing single-page-application using JWT token
Posted by Suresh Marru <sm...@apache.org>.
Hi Isuru,
The images got dropped, can you please add them to wiki and share a link?
Thanks,
Suresh
> On Jul 8, 2020, at 4:55 PM, Isuru Ranawaka <ir...@gmail.com> wrote:
>
> Hi Shivam, Anuj
>
> thanks for your comments on this. Please find and below description and
> comments, it might helpful for further understanding of the message flow of
> authentication and come up with a good design.
>
>
> The first figure depicts endpoint types for external applications to
> integrate with Custos services. Non browser applications can directly
> integrate with Custos using Python, Java, or Rest endpoints as preferred.
>
> Integrating browser applications is not straightforward with python SDK or
> JAVA SDK, because it might require some framework to cross the bridge
> between frontend client side code to server side code. (e.g Django
> framework). But, browser apps can directly use Rest endpoints for
> integration.
>
> *How Authentication Works*
>
> All clients are confidential clients for Custos. The minimum
> authentication mechanism for APIs is to use basic auth with base64 encoded
> Custos credentials. Application should securely store Custos secret and use
> that for basic authentication. Since, this is static, I guess storing that
> won’t be an issue.
>
> Some Custos APIs and application APIs require user access tokens to
> authenticate.
>
> At first login, Access token , ID token and Refresh token are issued in the
> response body in JWT. Subsequent calls to API require an access token of
> the logged user to authenticate.
>
> We need to finalize methods to store access token, refresh token and Id
> token. As Shivam , anuj suggested can use local storage, cookies or API
> Gateway approach. Any ideas on
> - How to handle silent refresh for invalidated tokens
> - Synchronizing logouts for multiple tabs
>
> On Tue, Jul 7, 2020 at 9:32 PM Suresh Marru <smarru@apache.org <ma...@apache.org>> wrote:
>
>> Thanks Anuj for your insights.
>>
>> Hi Isuru,
>>
>> It might help draw up an architecture of front end UI components to
>> backend security gateway to brainstorm this and arrive at a consensus of
>> handling API security for UI’s.
>>
>> Suresh
>>
>> On Jul 7, 2020, at 7:52 PM, anuj bhandar <bh...@gmail.com> wrote:
>>
>> I agree with your research, Options [1] & [2] are *not* recommended.
>>
>> We use AWS Amplify (https://aws.amazon.com/amplify/) to handle that
>> scenario, our tech stack comprises React front-end, AWS Amplify integrated
>> with our company's SSO provider, and an Rails API backend.
>>
>> Using a third party like AWS Amplify will not handle all the security
>> concerns, you will have to pay special attention to Token Validity. JWT
>> claims offer a good amount of control if set up properly (
>> https://tools.ietf.org/html/rfc7519).
>>
>> I am not sure if this was helpful. Happy to help wherever I can.
>>
>> Thanks,
>> *Anuj Bhandar*
>> Intuit Inc.
>>
>> On Tue, Jul 7, 2020 at 3:52 PM Rastogi, Shivam <sr...@iu.edu> wrote:
>>
>>> Hi Everyone,
>>>
>>>
>>> Just wanted to check if anyone has any experience in securing Single Page
>>> Webapps using JWT tokens.
>>>
>>>
>>>
>>> *Challenge*
>>>
>>> The challenge we are facing is how to store the JWT token at the
>>> client-side in the browser which will be used to securely call the back-end
>>> APIs.
>>>
>>>
>>> *Background*
>>>
>>> We are working on the custos UI portal and one of the design options that
>>> we are considering is to directly call the custos backend APIs from
>>> client-side javascript. The basic flow would look like:
>>>
>>>
>>> 1. User logins using username and password from the login screen using
>>> login API
>>>
>>> 2. JWT token and basic user-information is returned to the client in
>>> response.
>>>
>>> 3. In subsequent API requests, user will send this authentication token.
>>> But,how to store this token at client-side?
>>>
>>>
>>> *Options*
>>>
>>> 1. *Store it in localStorage* - This is not considered to be secure
>>> as localstorage is vulnerable to XSS attacks-
>>> https://dev.to/rdegges/please-stop-using-local-storage-1i04 <https://dev.to/rdegges/please-stop-using-local-storage-1i04> -
>>> 2. *Store the JWT token in httpOnly cookie -* Browser adds the cookie
>>> to all the API calls - vulnerable to CSRF attacks and need to be protected
>>> using CSRF token or in some other manner. Do you have any experience
>>> implementing these securely?
>>>
>>>
> I guess httpOnly cookie is added from the server-side. But that won't be
> feasible with the current approach. Custos provides access tokens in the
> body, and not capable of handling cookies. I guess we can achieve this via
> intermediate proxy. any thoughts?
>
>
>>> 1.
>>> 2. *Have an authentication middleware(API gateway) -* All user
>>> requests are routed to API-gateway which authenticates the users using
>>> sessionId and then re-routes the requests to the API by including the users
>>> JWT token or session information. More of a traditional way of doing
>>> things, but some big companies use this approach like Airbnb as per this
>>> article -
>>> https://medium.com/airbnb-engineering/building-services-at-airbnb-part-2-142be1c5d506
>>>
>>>
>>>
>>> It would be really helpful if you can provide any inputs or share your
>>> experience with SPAs.
>>>
>>>
>>> Thanks and regards,
>>>
>>> Shivam Rastogi
>>>
>>
>>
>
> --
> Research Software Engineer
> Indiana University, IN
Re: [Discussion] Securing single-page-application using JWT token
Posted by Isuru Ranawaka <ir...@gmail.com>.
Hi Shivam, Anuj
thanks for your comments on this. Please find and below description and
comments, it might helpful for further understanding of the message flow of
authentication and come up with a good design.
The first figure depicts endpoint types for external applications to
integrate with Custos services. Non browser applications can directly
integrate with Custos using Python, Java, or Rest endpoints as preferred.
Integrating browser applications is not straightforward with python SDK or
JAVA SDK, because it might require some framework to cross the bridge
between frontend client side code to server side code. (e.g Django
framework). But, browser apps can directly use Rest endpoints for
integration.
*How Authentication Works*
All clients are confidential clients for Custos. The minimum
authentication mechanism for APIs is to use basic auth with base64 encoded
Custos credentials. Application should securely store Custos secret and use
that for basic authentication. Since, this is static, I guess storing that
won’t be an issue.
Some Custos APIs and application APIs require user access tokens to
authenticate.
At first login, Access token , ID token and Refresh token are issued in the
response body in JWT. Subsequent calls to API require an access token of
the logged user to authenticate.
We need to finalize methods to store access token, refresh token and Id
token. As Shivam , anuj suggested can use local storage, cookies or API
Gateway approach. Any ideas on
- How to handle silent refresh for invalidated tokens
- Synchronizing logouts for multiple tabs
On Tue, Jul 7, 2020 at 9:32 PM Suresh Marru <sm...@apache.org> wrote:
> Thanks Anuj for your insights.
>
> Hi Isuru,
>
> It might help draw up an architecture of front end UI components to
> backend security gateway to brainstorm this and arrive at a consensus of
> handling API security for UI’s.
>
> Suresh
>
> On Jul 7, 2020, at 7:52 PM, anuj bhandar <bh...@gmail.com> wrote:
>
> I agree with your research, Options [1] & [2] are *not* recommended.
>
> We use AWS Amplify (https://aws.amazon.com/amplify/) to handle that
> scenario, our tech stack comprises React front-end, AWS Amplify integrated
> with our company's SSO provider, and an Rails API backend.
>
> Using a third party like AWS Amplify will not handle all the security
> concerns, you will have to pay special attention to Token Validity. JWT
> claims offer a good amount of control if set up properly (
> https://tools.ietf.org/html/rfc7519).
>
> I am not sure if this was helpful. Happy to help wherever I can.
>
> Thanks,
> *Anuj Bhandar*
> Intuit Inc.
>
> On Tue, Jul 7, 2020 at 3:52 PM Rastogi, Shivam <sr...@iu.edu> wrote:
>
>> Hi Everyone,
>>
>>
>> Just wanted to check if anyone has any experience in securing Single Page
>> Webapps using JWT tokens.
>>
>>
>>
>> *Challenge*
>>
>> The challenge we are facing is how to store the JWT token at the
>> client-side in the browser which will be used to securely call the back-end
>> APIs.
>>
>>
>> *Background*
>>
>> We are working on the custos UI portal and one of the design options that
>> we are considering is to directly call the custos backend APIs from
>> client-side javascript. The basic flow would look like:
>>
>>
>> 1. User logins using username and password from the login screen using
>> login API
>>
>> 2. JWT token and basic user-information is returned to the client in
>> response.
>>
>> 3. In subsequent API requests, user will send this authentication token.
>> But,how to store this token at client-side?
>>
>>
>> *Options*
>>
>> 1. *Store it in localStorage* - This is not considered to be secure
>> as localstorage is vulnerable to XSS attacks-
>> https://dev.to/rdegges/please-stop-using-local-storage-1i04 -
>> 2. *Store the JWT token in httpOnly cookie -* Browser adds the cookie
>> to all the API calls - vulnerable to CSRF attacks and need to be protected
>> using CSRF token or in some other manner. Do you have any experience
>> implementing these securely?
>>
>>
I guess httpOnly cookie is added from the server-side. But that won't be
feasible with the current approach. Custos provides access tokens in the
body, and not capable of handling cookies. I guess we can achieve this via
intermediate proxy. any thoughts?
>> 1.
>> 2. *Have an authentication middleware(API gateway) -* All user
>> requests are routed to API-gateway which authenticates the users using
>> sessionId and then re-routes the requests to the API by including the users
>> JWT token or session information. More of a traditional way of doing
>> things, but some big companies use this approach like Airbnb as per this
>> article -
>> https://medium.com/airbnb-engineering/building-services-at-airbnb-part-2-142be1c5d506
>>
>>
>>
>> It would be really helpful if you can provide any inputs or share your
>> experience with SPAs.
>>
>>
>> Thanks and regards,
>>
>> Shivam Rastogi
>>
>
>
--
Research Software Engineer
Indiana University, IN
Re: [Discussion] Securing single-page-application using JWT token
Posted by Isuru Ranawaka <ir...@gmail.com>.
Hi Shivam, Anuj
thanks for your comments on this. Please find and below description and
comments, it might helpful for further understanding of the message flow of
authentication and come up with a good design.
The first figure depicts endpoint types for external applications to
integrate with Custos services. Non browser applications can directly
integrate with Custos using Python, Java, or Rest endpoints as preferred.
Integrating browser applications is not straightforward with python SDK or
JAVA SDK, because it might require some framework to cross the bridge
between frontend client side code to server side code. (e.g Django
framework). But, browser apps can directly use Rest endpoints for
integration.
*How Authentication Works*
All clients are confidential clients for Custos. The minimum
authentication mechanism for APIs is to use basic auth with base64 encoded
Custos credentials. Application should securely store Custos secret and use
that for basic authentication. Since, this is static, I guess storing that
won’t be an issue.
Some Custos APIs and application APIs require user access tokens to
authenticate.
At first login, Access token , ID token and Refresh token are issued in the
response body in JWT. Subsequent calls to API require an access token of
the logged user to authenticate.
We need to finalize methods to store access token, refresh token and Id
token. As Shivam , anuj suggested can use local storage, cookies or API
Gateway approach. Any ideas on
- How to handle silent refresh for invalidated tokens
- Synchronizing logouts for multiple tabs
On Tue, Jul 7, 2020 at 9:32 PM Suresh Marru <sm...@apache.org> wrote:
> Thanks Anuj for your insights.
>
> Hi Isuru,
>
> It might help draw up an architecture of front end UI components to
> backend security gateway to brainstorm this and arrive at a consensus of
> handling API security for UI’s.
>
> Suresh
>
> On Jul 7, 2020, at 7:52 PM, anuj bhandar <bh...@gmail.com> wrote:
>
> I agree with your research, Options [1] & [2] are *not* recommended.
>
> We use AWS Amplify (https://aws.amazon.com/amplify/) to handle that
> scenario, our tech stack comprises React front-end, AWS Amplify integrated
> with our company's SSO provider, and an Rails API backend.
>
> Using a third party like AWS Amplify will not handle all the security
> concerns, you will have to pay special attention to Token Validity. JWT
> claims offer a good amount of control if set up properly (
> https://tools.ietf.org/html/rfc7519).
>
> I am not sure if this was helpful. Happy to help wherever I can.
>
> Thanks,
> *Anuj Bhandar*
> Intuit Inc.
>
> On Tue, Jul 7, 2020 at 3:52 PM Rastogi, Shivam <sr...@iu.edu> wrote:
>
>> Hi Everyone,
>>
>>
>> Just wanted to check if anyone has any experience in securing Single Page
>> Webapps using JWT tokens.
>>
>>
>>
>> *Challenge*
>>
>> The challenge we are facing is how to store the JWT token at the
>> client-side in the browser which will be used to securely call the back-end
>> APIs.
>>
>>
>> *Background*
>>
>> We are working on the custos UI portal and one of the design options that
>> we are considering is to directly call the custos backend APIs from
>> client-side javascript. The basic flow would look like:
>>
>>
>> 1. User logins using username and password from the login screen using
>> login API
>>
>> 2. JWT token and basic user-information is returned to the client in
>> response.
>>
>> 3. In subsequent API requests, user will send this authentication token.
>> But,how to store this token at client-side?
>>
>>
>> *Options*
>>
>> 1. *Store it in localStorage* - This is not considered to be secure
>> as localstorage is vulnerable to XSS attacks-
>> https://dev.to/rdegges/please-stop-using-local-storage-1i04 -
>> 2. *Store the JWT token in httpOnly cookie -* Browser adds the cookie
>> to all the API calls - vulnerable to CSRF attacks and need to be protected
>> using CSRF token or in some other manner. Do you have any experience
>> implementing these securely?
>>
>>
I guess httpOnly cookie is added from the server-side. But that won't be
feasible with the current approach. Custos provides access tokens in the
body, and not capable of handling cookies. I guess we can achieve this via
intermediate proxy. any thoughts?
>> 1.
>> 2. *Have an authentication middleware(API gateway) -* All user
>> requests are routed to API-gateway which authenticates the users using
>> sessionId and then re-routes the requests to the API by including the users
>> JWT token or session information. More of a traditional way of doing
>> things, but some big companies use this approach like Airbnb as per this
>> article -
>> https://medium.com/airbnb-engineering/building-services-at-airbnb-part-2-142be1c5d506
>>
>>
>>
>> It would be really helpful if you can provide any inputs or share your
>> experience with SPAs.
>>
>>
>> Thanks and regards,
>>
>> Shivam Rastogi
>>
>
>
--
Research Software Engineer
Indiana University, IN