@manicode nice talking with you yesterday. Follow-up on #OAuth implicit flow topic. You said don't use it. To my knowledge this is still the BCP per the #IETF RFC6749 for user-agent-based clients. Thoughts?
3
Also RFC6749 is really high level. Consider reading RFC8252 for best practice advice on native and mobile clients. Consider auth code flow for web apps and OIDC if you’re identifying users.
1
We do implement native apps per RFC8252 including code flow, custom tabs and PKCE, and we use OIDC for authentication to web apps. But doing ua-based-apps / SPAs right is ambiguous at best and I keep hoping for the @oauth_2 WG to begin work on an ua-based client BCP.
1
2
BCP for public UA clients: * use the authorization code flow * omit client secret * strict redirect URI validation Some citations and more info: aaronparecki.com/oauth-2-sim…
3
1
3
and what about for storing the access token in the browser?
1
Replying to @lewiada @manicode @oauth_2
Sadly there isn't a satisfying answer to that. Anything that your JS can use to store any token is vulnerable to XSS. The only secure option is cookies, but that won't work with OAuth. stormpath.com/blog/where-to-…

Apr 24, 2018 · 7:07 PM UTC

3
1
2
Replying to @aaronpk @lewiada @oauth_2
I agree. All browser storage methods can be abused by XSS. XSS is game over. You can try various techniques to verify different browser characteristics after theft but meh. Real answer is token binding standards of the future...
1
Replying to @aaronpk @lewiada @oauth_2
tools.ietf.org/html/draft-ie… tools.ietf.org/html/draft-ie… tools.ietf.org/html/draft-ie… tools.ietf.org/html/draft-ie… openid.net/specs/openid-conn… tools.ietf.org/html/draft-ie…
Replying to @aaronpk @lewiada @oauth_2
And even if you use HTTPOnly secure same-site cookies XSS can force a forged request of any nature: XSS is game over. Nothing today solves that issue. In the future maybe token binding will stop attackers from using stolen tokens... but not replaying them from the victims browser
1