Hi Suresh, please find the inline URL
On Wed, Jul 8, 2020 at 5:02 PM Suresh Marru <[email protected]> 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 <[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. > 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 <[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 > > -- Research Software Engineer Indiana University, IN
