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

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/