OAuth 2.0 Incremental Authorization
draft-ietf-oauth-incremental-authz-04
OAuth Working Group W. Denniss
Internet-Draft Google
Intended status: Standards Track May 3, 2020
Expires: November 4, 2020
OAuth 2.0 Incremental Authorization
draft-ietf-oauth-incremental-authz-04
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.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
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 November 4, 2020.
Copyright Notice
Copyright (c) 2020 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
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
Denniss Expires November 4, 2020 [Page 1]
Internet-Draft OAuth 2.0 Incremental Authorization May 2020
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Notational Conventions . . . . . . . . . . . . . . . . . . . 3
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Incremental Auth for Confidential Clients . . . . . . . . . . 3
5. Incremental Auth for Public Clients . . . . . . . . . . . . . 4
6. Usability Considerations . . . . . . . . . . . . . . . . . . 4
6.1. Handling Denials . . . . . . . . . . . . . . . . . . . . 4
6.2. Handling Scope Reductions . . . . . . . . . . . . . . . . 5
7. Alternative Approaches . . . . . . . . . . . . . . . . . . . 5
7.1. Alternative for Public Clients . . . . . . . . . . . . . 6
7.2. Alternative for Confidential Clients . . . . . . . . . . 6
8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 6
8.1. Requesting Authorization In Context . . . . . . . . . . . 6
8.2. Preventing Overbroad Authorization Requests . . . . . . . 7
8.3. Authorization Correlation . . . . . . . . . . . . . . . . 7
8.4. Previously Granted Scopes . . . . . . . . . . . . . . . . 8
9. Discovery Metadata . . . . . . . . . . . . . . . . . . . . . 8
10. Security Considerations . . . . . . . . . . . . . . . . . . . 8
10.1. Public Client Impersonation . . . . . . . . . . . . . . 8
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
11.1. OAuth Parameters Registry . . . . . . . . . . . . . . . 9
11.2. OAuth Extensions Error Registration . . . . . . . . . . 9
11.3. OAuth 2.0 Authorization Server Metadata . . . . . . . . 9
12. Normative References . . . . . . . . . . . . . . . . . . . . 10
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 10
Appendix B. Document History . . . . . . . . . . . . . . . . . . 10
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction
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
Show full document text