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]> 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 -
>> 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
