draft-lodderstedt-oauth-multiple-access-tokens.xml

<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="exp"
     docName="draft-lodderstedt-oauth-multiple-access-tokens-00"
     ipr="trust200902">
  <front>
    <title abbrev="Abbreviated-Title">Multiple Access Tokens</title>

    <author fullname="Torsten Lodderstedt" initials="T." surname="Lodderstedt">
      <organization>Deutsche Telekom</organization>

      <address>
        <email>torsten@lodderstedt.net</email>
      </address>
    </author>

    <date day="6" month="November" year="2012" />

    <area>Security Area</area>

    <workgroup>OAuth Working Group</workgroup>

    <keyword>Draft</keyword>

    <abstract>
      <t>This document proposes an extension to the OAuth v2 specification,
      which allows a client to request authorization to access different
      resource server at once and sub-sequently obtain
      resource-servers-specific access tokens based on a single refresh token.
      This mechanism allows OAuth deployments to use distinct access tokens
      for different resource servers while removing the burden for the
      resource owner to run through the authorization process a couple of
      times.</t>
    </abstract>

    <note title="Requirements Language">
      <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
      "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
      document are to be interpreted as described in <xref
      target="RFC2119">RFC 2119</xref>.</t>
    </note>
  </front>

  <middle>
    <section title="Introduction">
      <t>OAuth v2 [] distinguishes the role of resource server and
      authorization server and that way also enables deployments where a
      single authorization server is responsible for authorizing access to
      multiple, independent resource servers.</t>

      <t>It may be expected that more and more clients will integrate (or
      mash-up) several of such services. As an example, one might imagine a
      communication client integrating e-Mail via IMAP, Voice over IP using
      the SIP protocol, contacts via SyncML over HTTP, and webstorage access
      (e.g. for e-Mail attachments) using HTTP/WebDAV. For a particular
      end-user, the client may discover that all of the end-user's services
      rely on the same OAuth2-based authorization server because they are
      provided by the same organization. For reasons of simplicity and user
      experience, the client may want to acquire access authorization to all
      services in a single authorization flow. Another example of
      multi-service clients are OpenId Connect [openid&nbhy;connect] clients.
      Beside access to identity data (user data service) they may also require
      access to other user resources.</t>

      <t>Unfortunately, the current protocol design only allows to request and
      issue a single access token per end-user authorization flow. This
      restriction force deployments to issue tokens valid for multiple
      resources servers, which significantly limits applicability of the
      OAuth2 protocol and imposes a security threats as well.</t>

      <t><list style="symbols">
          <t>The need to issue multi-audience tokens imposes a major security
          threat on end-users. Every resource server receiving such a token
          can use it to invoke requests on behalf of the end-user on other
          resource servers this particular token is valid for. The token may
          even be accidentially exposed to an adversary by way of HTTP
          referers or log files. The impact of such an incident may be
          significant (e.g. disclosure of health care data, financial looses)
          since such tokens are powerful like passwords.</t>

          <t>For reasons of operational security, authorization servers should
          use different secrets for signing and encrypting self-contained
          tokens for different servers. This especially holds, if the resource
          servers are operated at different locations and by partner
          organisations. An archetype of this approach is the Kerberos
          protocol.</t>

          <t>Different services may, for the same end-user, require different
          identities attested by an access token. Examples range from network
          identities, such as fixed-line port, radius session, IMSI, to user
          identities, product booking instances (e-mail box, MSISDN), customer
          identities, contract numbers or federated identities. Such
          identities should be asserted by different tokens.</t>

          <t>Different services may require different if not disjunct
          attributes and authorization data associated with the attested
          identities. Keeping this data separated in different tokens promotes
          data privacy (cf. [laws&nbhy;of&nbhy;identity] (Cameron, K.,
          &ldquo;The Laws of Identity,&rdquo; May 2005.) , Law 2). Moreover,
          it is good practice in identity management to issue service-specific
          identities.</t>

          <t>Different services may require different token formats (e.g. SWT
          vs. SAML assertions vs. session handles)</t>
        </list>This internet draft proposes a new response type
      "code_advanced" and a new grant type "authorization_code_advanced",
      which allow the client to request a refresh token associated with
      mutiple scopes and to obtain different access tokens from this refresh
      token later on.</t>

      <t>Note: the client may also omit the scopes if the scopes of the
      refresh token are determined by a policy at the authorization
      server.</t>

      <t>Note: the same pattern could be applied to the resource owner
      password flow</t>

      <t>The Client requests multiple scopes in the request.</t>

      <figure>
        <artwork><![CDATA[GET /authorize?response_type=code_advanced&
client_id=s6BhdRkqt3&state=xyz&
redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb&
scopes=3&scope.1=email&scope.2=webdav&scope.3=voip HTTP/1.1 
Host: server.example.com]]></artwork>
      </figure>

      <t></t>

      <figure>
        <artwork><![CDATA[HTTP/1.1 302 Found
Location: https://client.example.com/cb?code=SplxlOBeZQQYbYS6WxSbIA
           &state=xyz]]></artwork>
      </figure>

      <t>There is an additional "scope" parameter for the access token
      request, which defines the scope of the access token returned for the
      code exchange. It must be one out of the scopes requested in the initial
      request to the end-user authorization endpoint.</t>

      <figure>
        <artwork><![CDATA[POST /token HTTP/1.1
Host: server.example.com
Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
Content-Type: application/x-www-form-urlencoded

grant_type=authorization_code_advanced&code=SplxlOBeZQQYbYS6WxSbIA
&redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb&
scope=email]]></artwork>
      </figure>

      <t>The new refresh token is associated with all the scopes the client
      initially requested on the end-user authorization endpoint.</t>

      <figure>
        <artwork><![CDATA[HTTP/1.1 200 OK
Content-Type: application/json;charset=UTF-8
Cache-Control: no-store
Pragma: no-cache

{
  "access_token":"2YotnFZFEjr1zCsicMWpAA",
  "token_type":"bearer",
  "expires_in":3600,
  "refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA",
}]]></artwork>
      </figure>

      <t>The client can then obtain further access token for any of the
      requested scopes using the grant type refresh_token.</t>
    </section>

    <section anchor="IANA" title="IANA Considerations">
      <t>This document makes no request of IANA.</t>

      <t>Note to RFC Editor: this section may be removed on publication as an
      RFC.</t>
    </section>

    <section anchor="Security" title="Security Considerations">
      <t></t>
    </section>

    <section anchor="Acknowledgements" title="Acknowledgements">
      <t></t>
    </section>
  </middle>

  <back>
    <references title="Normative References">
      <?rfc include="reference.RFC.2119"?>
<?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.6749.xml' ?>
    </references>

    <references title="Informative References">
      <reference anchor="InfRef">
        <front>
          <title></title>

          <author>
            <organization></organization>
          </author>

          <date year="2004" />
        </front>
      </reference>
    </references>

    <section title="An Appendix">
      <t></t>
    </section>
  </back>
</rfc>