OAuth for Single-Page Apps (javascript apps) Best Practices Recommendations

From IIW

OAuth for Single-Page Apps (javascript apps): Best Practices Recommendations

Day/Session:Wednesday 2I

Convener:Aaron Parecki

Notes-taker(s): Tom Brown

Tags for the session - technology discussed/ideas considered:


Discussion notes, key understandings, outstanding questions, observations, and, if appropriate to this discussion: action items, next steps:

  • Problems with Oauth implicit flow. We can do better
  • BCP – best practices (get a number filled by a series of RFCs that can change over time. As close as IETF gets to a living document
  • Not trying to break spec
  • Nothing necessarily wrong with fragment but returning access token in front channel is susceptible to interception and replay attacks
  • also, we have browser history api now so don't need fragment
  • with JS, not client authentication
  • Justin R.: no way to confirm access token is the one I requested
  • AS has no assurance that code was sent to the right place
  • Authorization code by itself is better than implicit. If you add PKCE, then you solve stolen code
  • Justin R.: Many implementation don't do CORS because they haven't thought of it
  • Torsten: Nonce not defined in OAuth 2 spec and went with PKCE
  • Registering urls, not allowing wildcards needed for JS since no client authentication
  • What is a JS app? (electron is a native app written in JS):
    • App running in a browser
    • Not JS in native wrapper
    • Code running in user agent delivered from a domain
  • “token agent pattern” noted but seems out of scope
  • In case of first party app, it sometimes doesn't make sense for user to leave the page (maybe there are no 3rd party apps)
  • Anabelle: Popups are a pain
  • If user doesn't leave page, there are losses: no single sign-on, you can't do FIDO, no 3rd party IdPs