Minutes interim-2020-oauth-03: Mon 18:00
minutes-interim-2020-oauth-03-202004061800-02

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