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 <[email protected]> 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 <[email protected] > <mailto:[email protected]>> 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 <[email protected]> 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 <[email protected]> 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
