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

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
 OATH 2.0 Security Best Current Practice
        Version 15 - (Draft)
            Minor changes to 14
            Security BCP to OAuth 2.0
                Updates: Comprehensive threat model
                Descriptions of M2M
            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
                    Screen-shots
                    Mitigation should be used, like PKCE.
                    Before it was stated that you should not use token

                    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 replies. Instead of
                    "RECOMMEND", maybe "EXAMPLE" 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 ith 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 great 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 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 specifics 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.