Internet DRAFT - draft-richer-oauth-json-request
draft-richer-oauth-json-request
Web Authorization Protocol J. Richer
Internet-Draft Bespoke Engineering
Intended status: Standards Track 9 July 2020
Expires: 10 January 2021
OAuth 2.0 JSON Request
draft-richer-oauth-json-request-00
Abstract
This document specifies a method for sending requests to OAuth
endpoints as a JSON document instead of a form-encoded document.
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 10 January 2021.
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 the Trust Legal Provisions and are
provided without warranty as described in the Simplified BSD License.
Richer Expires 10 January 2021 [Page 1]
Internet-Draft oauth-json-request July 2020
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Conventions and Terminology . . . . . . . . . . . . . . . 2
2. Formatting a request as JSON . . . . . . . . . . . . . . . . 3
2.1. Token Endpoint Parameters . . . . . . . . . . . . . . . . 3
3. Sending a request as JSON . . . . . . . . . . . . . . . . . . 3
4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 3
5. Metadata . . . . . . . . . . . . . . . . . . . . . . . . . . 6
6. Security Considerations . . . . . . . . . . . . . . . . . . . 6
7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 6
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
10. Normative References . . . . . . . . . . . . . . . . . . . . 7
11. Informative References . . . . . . . . . . . . . . . . . . . 7
Appendix A. Document History . . . . . . . . . . . . . . . . . . 8
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8
1. Introduction
The OAuth 2.0 authorization framework [RFC6749] uses form encoding
for requests to the token endpoint, and several extensions including
[RFC7009] and [RFC7662] also use this format for their own endpoints.
Additionally, due to this choice, several parameters such as the
"scope" parameter have a special serialization defined in the
protocol to allow it to be expressed within the string-based form
encoding format.
This draft defines a method for encoding all inputs to form-based
endpoints in the OAuth 2 protocol as JSON [RFC8259].
1.1. Conventions and Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
This specification uses the terms "access token", "refresh token",
"authorization server", "resource server", "authorization endpoint",
"authorization request", "authorization response", "token endpoint",
"grant type", "access token request", "access token response", and
"client" defined by The OAuth 2.0 Authorization Framework [RFC6749].
Richer Expires 10 January 2021 [Page 2]
Internet-Draft oauth-json-request July 2020
2. Formatting a request as JSON
The sender creates a JSON object to contain all parameters to the
target endpoint. For each parameter to be sent, the parameter name
is used as the object member name within that object. The value of
each parameter is encoded in JSON dependent on which parameter is
being sent.
Parameters that have a specific JSON encoding will have an indication
of the defining specification in the "json_encoding" column of the
IANA parameters registry table. If any element does not have a
specific encoding, its value MUST be the string value that would have
been used without this extension, without form-encoding.
2.1. Token Endpoint Parameters
JSON encoding of token endpoint parameters are defined as follows.
"scope": An array containing individual scope values, represented as
strings.
"authorization_details": An array of JSON objects as defined by
"draft-ietf-oauth-rar", without additional string encoding.
3. Sending a request as JSON
The requester sets an HTTP "Content-Type" header indicating that the
content is in JSON. The entity body MUST be the serialization of the
JSON object as defined in Section 2.
If the request is rejected with "415 Unsupported Media Type", the
requester MAY repeat the request using form encoding instead.
4. Examples
This example shows a request to the token endpoint for the
authorization code grant type.
POST /token HTTP/1.1
Host: as.example.com
Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
Content-Type: application/json
{
"grant_type": "authorization_code",
"code": "SplxlOBeZQQYbYS6WxSbIA",
"redirect_uri": "https://client.example.com/cb"
}
Richer Expires 10 January 2021 [Page 3]
Internet-Draft oauth-json-request July 2020
This example shows a request to the token endpoint with a refresh
token, the client's credentials, and a scope parameter.
POST /token HTTP/1.1
Host: as.example.com
Content-Type: application/json
{
"grant_type": "refresh_token",
"refresh_token": "tGzv3JOkF0XG5Qx2TlKWIA",
"client_id": "s6BhdRkqt3",
"client_secret": "7Fjfp0ZBr1KtDRbnfVdmIw",
"scope": [ "read", "write" ]
}
This example shows a rich authorization request "draft-ietf-oauth-
rar" to the token endpoint.
Richer Expires 10 January 2021 [Page 4]
Internet-Draft oauth-json-request July 2020
POST /token HTTP/1.1
Host: as.example.com
Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
Content-Type: application/json
{
"grant_type": "authorization_code",
"code": "SplxlOBeZQQYbYS6WxSbIA",
"redirect_uri": "https://client.example.com/cb",
"authorization_details": [
{
"type": "account_information",
"actions": [
"list_accounts",
"read_balances",
"read_transactions"
],
"locations": [
"https://example.com/accounts"
]
},
{
"type": "payment_initiation",
"actions": [
"initiate",
"status",
"cancel"
],
"locations": [
"https://example.com/payments"
],
"instructedAmount": {
"currency": "EUR",
"amount": "123.50"
},
"creditorName": "Merchant123",
"creditorAccount": {
"iban": "DE02100100109307118603"
},
"remittanceInformationUnstructured": "Ref Number Merchant"
}
]
}
This example shows a request to the introspection endpoint as defined
in [RFC7662].
Richer Expires 10 January 2021 [Page 5]
Internet-Draft oauth-json-request July 2020
POST /introspect HTTP/1.1
Host: as.example.com
Content-Type: application/json
{
"token": "2YotnFZFEjr1zCsicMWpAA"
}
This example shows a request to the revocation endpoint as defined in
[RFC7009].
POST /revoke HTTP/1.1
Host: as.example.com
Content-Type: application/json
{
"token": "45ghiukldjahdnhzdauz",
"token_type_hint": "refresh_token"
}
This example shows a request to the device authorization endpoint as
defined in [RFC8628].
POST /device_authorization HTTP/1.1
Host: as.example.com
Content-Type: application/json
{
"client_id": "1406020730",
"scope": [ "example_scope" ]
}
5. Metadata
The AS advertises support for JSON encoding using the metadata
parameter "json_input_supported" of type boolean. Absence of this
parameter indicates absence of support.
6. Security Considerations
As this specification provides an alternate encoding for existing
parameters, there are no additional security considerations.
7. Privacy Considerations
As this specification provides an alternate encoding for existing
parameters, there are no additional privacy considerations.
Richer Expires 10 January 2021 [Page 6]
Internet-Draft oauth-json-request July 2020
8. Acknowledgements
The authors would like to thank the engineering team of Authlete for
feedback and support.
9. IANA Considerations
TBD
* "json_input_supported" as metadata parameter
* "json_encoding" as column in OAuth parameters table
10. Normative References
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8628] Denniss, W., Bradley, J., Jones, M., and H. Tschofenig,
"OAuth 2.0 Device Authorization Grant", RFC 8628,
DOI 10.17487/RFC8628, August 2019,
<https://www.rfc-editor.org/info/rfc8628>.
[RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework",
RFC 6749, DOI 10.17487/RFC6749, October 2012,
<https://www.rfc-editor.org/info/rfc6749>.
[RFC7009] Lodderstedt, T., Ed., Dronia, S., and M. Scurtescu, "OAuth
2.0 Token Revocation", RFC 7009, DOI 10.17487/RFC7009,
August 2013, <https://www.rfc-editor.org/info/rfc7009>.
[RFC7662] Richer, J., Ed., "OAuth 2.0 Token Introspection",
RFC 7662, DOI 10.17487/RFC7662, October 2015,
<https://www.rfc-editor.org/info/rfc7662>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
11. Informative References
[RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
Interchange Format", STD 90, RFC 8259,
DOI 10.17487/RFC8259, December 2017,
<https://www.rfc-editor.org/info/rfc8259>.
Richer Expires 10 January 2021 [Page 7]
Internet-Draft oauth-json-request July 2020
Appendix A. Document History
[[ To be removed from the final specification ]]
-00
* Initial draft
Author's Address
Justin Richer
Bespoke Engineering
Email: ietf@justin.richer.org
Richer Expires 10 January 2021 [Page 8]
