Securing Web APIs from JavaScript/SPA Applications - Brock Allen

Modern web development means that more and more application code is running in the browser as JavaScript.
This architectural shift requires us to change how we perform authentication and authorization. Fortunately, using modern protocols such as OpenID Connect you don’t need to invent your own solution for this new environment. This session will show you the modern approach for browser-based JavaScript applications to authenticate users, and perform secure web api invocations. As you might expect, security is sufficiently complex and so even modern security comes with its own set of challenges. Luckily, we will show off some libraries that help manage this complexity so your application doesn’t have to.
Check out more of our talks in the following links!
NDC Conferences
ndcoslo.com
ndcconferences.com

[@girish8611]

This session such gem, not sure it has low hits. I never knew implicit flow outdated and way forward is Code+PKCE. Neatly explained with all scenario.

[@m.olivier722]

Extremely interesting! One of the best presentation I have ever seen on OIDC & Oauth. Thanks a lot.

[@nullphp]

Thanks for explaning these concepts so clearly

[@georget5874]

Very interesting. I might have a go at implementing this in a SPA.

[@kimgysen10]

This presentation is what I needed. Thanks for this.

[@csudab]

Finishes a chapter on cookies and talks about token authentication at 16:10
High level walkthrough the SPA token process 18:00
Walkthrough with technical detail 21:48

[@MrSachin411]

This is very good content. Many thanks for this. One thought, In this pkce flow how resource server can trust that token is being sent by Authorization server?

[@victorrocha9099]

awesome speech

[@mattmarkus4868]

49:04 Is the access token itself supposed to be updated with silent renew? It shows the expiration and session state being updated, not the token value. Anyone?

[@mattmarkus4868]

Where is the code for this little demo? It should be in the notes here like he said, but of course nothing is- not even the library.

[@mr.damien826]

How do I make sure that it is my spa doing the calls? And not some random person that copied my client_id?

[@surensingh123]

@
Mr.Damien , You need to provide the code verifier when exchanging the code for token at the token endpoint and your SPA is the only entity that knows it, so a random person can't get hold of the code verifier and "mimic" you.

[@stholy32]

Never store secure information using the Web Storage API (sessionStorage/localStorage) - its stored in plain text and any malicious code running in your browser can read it.
Instead of storing it on localStorage/sessionStorage, when the tokens are sent to the server, the server must send back a secure, httpOnly expiring cookie containing the tokens.This way, the SPA/client can make calls to the API while the browsers sends the cookie with which the server can use to know that the user is legitimate

[@MJDreams]

Can you give some resources related to that? Can't chrome extension have access also to httpOnly cookies?

[@AndyD89]

Yes, this talk although useful just skips over what to do with the access token, which is the most important point. As you say you should not store it in local storage.

[@AndyD89]

It is pretty worrying that a “security expert” stores access tokens in local storage without even a single mention of the dangers.

[@MJDreams]

@@AndyD89 but isn't like we could keep it in sessionStorage as access_token should have limited validation and should be refreshed every X time?

[@MJDreams]

I'm asking as it's not first talk security experts say it (some just said to keep it in sessionStorage) and avoid keeping refresh token in local/Session storage. So if any have some good/better resources on that topic please share.

[@mishasawangwan6652]

say SPA again.