Internet-Draft oauth-json-request July 2020
Richer Expires 10 January 2021 [Page]
Workgroup:
Web Authorization Protocol
Internet-Draft:
draft-richer-oauth-json-request-00
Published:
Intended Status:
Standards Track
Expires:
Author:
J. Richer
Bespoke Engineering

OAuth 2.0 JSON Request

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.

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].

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"
}

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.

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].

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.

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, , <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, , <https://www.rfc-editor.org/info/rfc8628>.
[RFC6749]
Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", RFC 6749, DOI 10.17487/RFC6749, , <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, , <https://www.rfc-editor.org/info/rfc7009>.
[RFC7662]
Richer, J., Ed., "OAuth 2.0 Token Introspection", RFC 7662, DOI 10.17487/RFC7662, , <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, , <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, , <https://www.rfc-editor.org/info/rfc8259>.

Appendix A. Document History

[[ To be removed from the final specification ]]

-00

  • Initial draft

Author's Address

Justin Richer
Bespoke Engineering