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

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:

oauth

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