--- 1/draft-ietf-oauth-incremental-authz-00.txt 2018-10-22 15:13:59.643181403 -0700 +++ 2/draft-ietf-oauth-incremental-authz-01.txt 2018-10-22 15:13:59.667181981 -0700 @@ -1,18 +1,18 @@ OAuth Working Group W. Denniss Internet-Draft Google -Intended status: Standards Track June 28, 2018 -Expires: December 30, 2018 +Intended status: Standards Track October 22, 2018 +Expires: April 25, 2019 OAuth 2.0 Incremental Authorization - draft-ietf-oauth-incremental-authz-00 + draft-ietf-oauth-incremental-authz-01 Abstract OAuth 2.0 authorization requests that include every scope the client might ever need can result in over-scoped authorization and a sub- optimal end-user consent experience. This specification enhances the OAuth 2.0 authorization protocol by adding incremental authorization, the ability to request specific authorization scopes as needed, when they're needed, removing the requirement to request every possible scope that might be needed upfront. @@ -25,21 +25,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on December 30, 2018. + This Internet-Draft will expire on April 25, 2019. Copyright Notice Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -58,32 +58,34 @@ 5. Incremental Auth for Public Clients . . . . . . . . . . . . . 4 6. Usability Considerations . . . . . . . . . . . . . . . . . . 4 6.1. Handling Denials . . . . . . . . . . . . . . . . . . . . 4 7. Alternative Approaches . . . . . . . . . . . . . . . . . . . 5 7.1. Alternative for Public Clients . . . . . . . . . . . . . 5 7.2. Alternative for Confidential Clients . . . . . . . . . . 5 8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 5 8.1. Requesting Authorization In Context . . . . . . . . . . . 5 8.2. Preventing Overbroad Authorization Requests . . . . . . . 6 8.3. Authorization Correlation . . . . . . . . . . . . . . . . 6 - 9. Security Considerations . . . . . . . . . . . . . . . . . . . 6 - 9.1. Public Client Impersonation . . . . . . . . . . . . . . . 6 - 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 - 10.1. OAuth Parameters Registry . . . . . . . . . . . . . . . 7 - 11. Normative References . . . . . . . . . . . . . . . . . . . . 7 + 9. Discovery Metadata . . . . . . . . . . . . . . . . . . . . . 6 + 10. Security Considerations . . . . . . . . . . . . . . . . . . . 7 + 10.1. Public Client Impersonation . . . . . . . . . . . . . . 7 + 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 + 11.1. OAuth Parameters Registry . . . . . . . . . . . . . . . 7 + 11.2. OAuth 2.0 Authorization Server Metadata . . . . . . . . 8 + 12. Normative References . . . . . . . . . . . . . . . . . . . . 8 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 8 - Appendix B. Document History . . . . . . . . . . . . . . . . . . 8 - Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8 + Appendix B. Document History . . . . . . . . . . . . . . . . . . 9 + Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9 1. Introduction - OAuth 2.0 clients may offer multiple features that requiring user + OAuth 2.0 clients may offer multiple features that require user authorization, but commonly not every user will use each feature. Without incremental authentication, applications need to either request all the possible scopes they need upfront, potentially resulting in a bad user experience, or track each authorization grant separately, complicating development. The goal of incremental authorization is to allow clients to request just the scopes they need, when they need them, while allowing them to store a single authorization grant for the user that contains the sum of the scopes granted. Thus, each new authorization request @@ -161,23 +163,25 @@ additional parameter: existing_grant OPTIONAL. The refresh token from the existing authorization grant. When processing the token exchange, in addition to the normal processing of such a request, the token endpoint MUST verify that token provided in the "existing_grant" parameter is unexpired and unrevoked, and was issued to the same client id and relates to the same user as the current authorization grant. If this verification - succeeds, the new refresh token issued in the Access Token Response - (Section 4.1.4 of ) SHOULD include authorization for the scopes in - the previous grant. + succeeds, the new access and refresh tokens issued in the Access + Token Response (Section 4.1.4 of ) MUST include authorization for the + scopes in the previous grant, unless the authorization server is + exercising its prerogative to "fully or partially ignore the scope + requested by the client" per Section 3.3 of OAuth 2.0 [RFC6749]. 6. Usability Considerations 6.1. Handling Denials A core principle of OAuth is that users may deny authorization requests for any reason. This remains true for incremental authorization requests. In the case of incremental authorization, clients may already have a valid authorization and receive a denial for an incremental authorization request (that is, an "access_denied" @@ -267,93 +271,136 @@ giving them more choice over which scopes they grant access to. Previously many apps would request an overly large number of scopes upfront (typically for all the features of the app, rather than the subset that the user is currently wishing to use). The scopes in such authorization grants are necessarily correlated with the same user as they are contained in a single authorization grant. Implementing this specification doesn't change that attribute, but it does improve user privacy overall by empowering the user to grant access in a more granular way. -9. Security Considerations +9. Discovery Metadata -9.1. Public Client Impersonation + Support for the incremental authorization MAY be declared in the + OAuth 2.0 Authorization Server Metadata [RFC8414] with the following + metadata: + + incremental_authz_types_supported + OPTIONAL. JSON array of OAuth 2.0 client types that are supported + for incremental authorization. The possible types, defined by + Section 2.1 of RFC6749, are "public", "confidential". + +10. Security Considerations + +10.1. Public Client Impersonation As documented in Section 8.6 of RFC 8252 [RFC8252], some public clients are susceptible to client impersonation, depending on the type of redirect URI used. If the "include_granted_scopes" feature documented in Section 4 is used by an impersonating client, it may receive a greater authorization grant than the user specifically approved for that client. For this reason, the "include_granted_scopes" feature MUST NOT be enabled for such public client requests. Note that there is no such restriction on the use of "existing_grant" feature documented in Section 5. While it is designed for public clients, it MAY be supported for all client types. -10. IANA Considerations +11. IANA Considerations This specification makes a registration request as follows: -10.1. OAuth Parameters Registry +11.1. OAuth Parameters Registry This specification registers the following parameters in the IANA OAuth Parameters registry defined in OAuth 2.0 [RFC6749]. o Parameter name: include_granted_scopes o Parameter usage location: authorization request o Change controller: IESG o Specification document(s): this document o Parameter name: existing_grant o Parameter usage location: token request o Change controller: IESG o Specification document(s): this document -11. Normative References +11.2. OAuth 2.0 Authorization Server Metadata + + This specification registers the following values in the IANA "OAuth + 2.0 Authorization Server Metadata" registry [IANA.OAuth.Parameters] + established by [RFC8414]. + + o Metadata Name: incremental_authz_types_supported + o Metadata Description: JSON array containing a list of client types + that support OAuth 2.0 Incremental Authorization [[ this + specification ]]. The possible types, defined by Section 2.1 of + RFC6749, are "public", "confidential". + o Change controller: IESG + o Specification Document: Section 9 of [[ this specification ]] + +12. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", RFC 6749, DOI 10.17487/RFC6749, October 2012, . [RFC8252] Denniss, W. and J. Bradley, "OAuth 2.0 for Native Apps", BCP 212, RFC 8252, DOI 10.17487/RFC8252, October 2017, . + [RFC8414] Jones, M., Sakimura, N., and J. Bradley, "OAuth 2.0 + Authorization Server Metadata", RFC 8414, + DOI 10.17487/RFC8414, June 2018, + . + + [IANA.OAuth.Parameters] + IANA, "OAuth Parameters", + . + Appendix A. Acknowledgements This document was produced in the OAuth working group under the chairpersonship of Rifaat Shekh-Yusef and Hannes Tschofenig with Benjamin Kaduk, and Eric Rescorla serving as Security Area Directors. The following individuals contributed ideas, feedback, and wording that shaped and formed the final specification: Yanna Wu, Marius Scurtescu, Jason Huang, Nicholas Watson, and Breno de Medeiros. Appendix B. Document History [[ to be removed by the RFC Editor before publication as an RFC ]] + 01 + + o Changed a SHOULD to a MUST in Section 5 regarding the protocol + behavior of incremental auth for public clients, while clarifying + that the authorization server retains the prerogative to do + whatever it wants. + + o Defined an OAuth Metadata entry. + 00 o Now a working group draft. draft-wdenniss-oauth-incremental-auth-01 o Added usability, privacy, and security considerations. o Documented alternative approaches.