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/ |