Minutes interim-2020-oauth-03: Mon 18:00
Web Authorization Protocol
||Minutes interim-2020-oauth-03: Mon 18:00
Minutes taker: Jared Jennings
- OAuth Security Topics
- Browser-based Apps
Questions / Agenda Topics
- The group confirmed there will be continued meetings every Monday (12:00 pm
| (UTC-04:00) Eastern Time (US & Canada)
OAUTH 2.0 Security Best Current Practice
Version 15 - (Draft)
Minor changes to 14
Added references to Security BCP to OAuth 2.0
Updates: Comprehensive threat model
Descriptions of MITM have been added
Working Group last call (version 13)
Various small improvements
expanded attack details and examples
restructured mitigation sections
Updated references for
Clients "SHOULD NOT" changed to "MUST NOT" "are advised to
implement countermeasures against open redirection."
"SHOULD" changed to "MUST" - provider to provide the
implementation-specific details or metadata
Mitigation should be used, like PKCE.
Annabelle: questioned that the spec recommends Mutual TLS be used
to sender-constrained or use of refresh token.
Justin: expressed sympathetic to Annabelle's concern and that we
are mostly worried about token replays. Instead of "RECOMMEND",
maybe providing examples as was recommended as previously.
Torsten: expressed the work that has been done and that
sender-constrained improvements have been the work of the last
three years of the group to reduce the risk.
Daniel: will propose a revised wording to the Implicit Grant
Question: Ready for publication?
Rifaat: Will there be any problem implementing the changes
suggestion/requested by the group today? Daniel: Will address the comments
and provide a new update tomorrow. Annabelle: Will there be a workgroup
last call? Rifaat: Confirmed that there will be a last call of the draft.
OAuth 2.0 for Browser-Based Apps
Includes recommendations for implementers building browser-based apps
using OAuth 2.0 MUST: Must use auth code flow with PKCE (no Implicit)
ensuring AS supports pKCE
using OAuth 2.0 state parameter
using OIDC nonce
Thanks to Mike Jones for the feedback
Disallow password grant
Allow refresh tokens in SPAs as long as they conform to the Security BCP
including editorial clarifications
- Security BCP was updated not to require, but recommend PKCE
- Should we update the guidance for browser-based apps as well?
- Section 9.6.3 does not address how the AS can be assured that the
token was received by the correct application (which PKCE solves) -
How can access token inject addressed in this scenario - References
to the alternative to PKCE
Example: Using the state parameter
- Can a signed request_uri be used as an alternative to exact
redirect URI matching - refresh tokens are generally used for
offline_access. Can we provide recommendations for revoking
refreshing tokens in a Browser-based environment?
- A Service Work can be used to perform the OAuth flow, get and
store access & refresh tokens. - Add this as an architectural
pattern to the document
- Mike Jones: Current text requires PKCE across examples. Mike
requests that the document makes it clear that either PKCE or
additional examples of how the attack can be addressed.
Aaron: requested that examples be given which detail the
different examples of the attack(s) or possible attacks.
Torsten: Questioned the scope of the BCP.
Mike: The simplest change being that it aligns with the
Security BCP that either noonce or PKCE be used as
recommendations. Mike's ask is that the document makes it clear
that PKCE is not required.
Annabelle: Also provided comments to the current topic. Felt
that it wouldn't be beneficial to replicate what the Security
BCP already covers.
continued discussions of the definition of "client", including
Torsten: not all SPA's will be public clients. Including a
confidential backend. SPA's can be confidential.
Justin: In the case that Torsten outlined, the OAuth client is
actually the backend and not the SPA.
Vittorio: The wording of Browser-based with backends access
token reads weirdly. Additional discussion will email the list
for continued discussion.
Aaron: PKCE or NONCE - discussion and how the request can be
made, including what code/token can be used. (Rule-out implicit
token and id_token).
Torsten: agreed with Mike that we should not include tokens
that issue a token on the front-side.
Annabelle: Don't include a token and MUST include code?
Justin: Agreed that it would be good if we could include
the "why" specific codes make sense and which ones do not
make sense in specific scenarios. How we can best help
developers navigate the code registry.
Aaron: We are saying that you MUST use either PKCE or nonce
and should use the following specific code. Plus some
Additional discussions will continue on the next call and Aaron
will post to the list with threaded topics.
Mike requested another draft before the next call, with all the
feedback and changes that had been discussed.
Meeting adjourned and the group will meet again next Monday.