Minutes taker: Jared Jennings

Topics
- 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)

Daniel Fett
 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)
    Editorial Changes
        Attacker Model
        Various small improvements
            clarifications
            definitions (CSRF)
            expanded attack details and examples
            restructured mitigation sections
        Updated references for
    Normative Changes
        Open Redirectors:
            Clients "SHOULD NOT" changed to "MUST NOT" "are advised to implement countermeasures against open redirection."
        PKCE
            "SHOULD" changed to "MUST" - provider to provide the implementation-specific details or metadata
        Implicit Grant
            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 section.

    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.


Aaron Parecki
    OAuth 2.0 for Browser-Based Apps
    DRAFT
        Includes recommendations for implementers building browser-based apps using OAuth 2.0
        MUST: Must use auth code flow with PKCE (no Implicit)
        MUST:
            Protect CSRF
            ensuring AS supports pKCE
            using OAuth 2.0 state parameter
            using OIDC nonce
        Changes
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
        Open Questions
            - 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?
        New Items
            - 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

        Questions:
            - 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 client_id's.

                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 examples.

                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.

Referenced Documents
https://datatracker.ietf.org/meeting/interim-2020-oauth-03/session/oauth