rfc6819.xml

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">

<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="4"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<?rfc strict="no"?>
<?rfc rfcedstyle="yes"?>

<rfc category="info" number="6819"
     ipr="trust200902" submissionType="IETF" consensus="yes">

  <front>
    <title abbrev="OAuth 2.0 Security">OAuth 2.0 Threat Model and Security Considerations</title>

    <author fullname="Torsten Lodderstedt" initials="T." role="editor"
            surname="Lodderstedt">
      <organization>Deutsche Telekom AG</organization>
      <address>
        <email>torsten@lodderstedt.net</email>
      </address>
    </author>

    <author fullname="Mark McGloin" initials="M." surname="McGloin">
      <organization>IBM</organization>
      <address>
        <email>mark.mcgloin@ie.ibm.com</email>
      </address>
    </author>

    <author fullname="Phil Hunt" initials="P." surname="Hunt">
      <organization>Oracle Corporation</organization>
      <address>
        <email>phil.hunt@yahoo.com</email>
      </address>
    </author>

    <date month="January" year="2013" />

    <area>Security Area</area>

    <workgroup>OAuth Working Group</workgroup>

    <keyword>authorization</keyword>
    <keyword>authentication</keyword>
    <keyword>token</keyword>
    <keyword>counter-measures</keyword>
    <keyword>HTTP</keyword>
    <keyword>REST</keyword>

    <abstract>
      <t>
        本ドキュメントでは, OAuth 2.0仕様が定めるSecurity Considerationsの範囲を超え,
        OAuth 2.0プロトコルに関する包括的脅威モデルを基に, さらなるセキュリティ上の検討項目を示す.
      </t>
      <!--
      <t>This document gives additional security considerations for OAuth,
      beyond those in the OAuth 2.0 specification, based on a comprehensive
      threat model for the OAuth 2.0 protocol.</t>
      -->
    </abstract>
  </front>

  <middle>
    <section title="Introduction">
      <t>
        本ドキュメントでは, OAuth仕様が定めるSecurity Considerationsの範囲を超え,
        OAuth 2.0プロトコル <xref target="RFC6749"></xref> に関する包括的脅威モデルを基に, さらなるセキュリティ上の検討項目を示す.
        本ドキュメントは以下の項目について扱う.
        <list style="symbols">
          <t>
            脅威モデル策定の前提となる仮説およびその影響範囲を定める.
          </t>
          <t>
            OAuthプロトコルのセキュリティ上の特徴について述べ, それらが攻撃阻止のためにどのような役割を持つかをまとめる.
          </t>
          <t>
            OAuthの包括的脅威モデル, およびそれらへの対抗策についてまとめる.
          </t>
        </list>
        ここで述べる脅威には, OAuthトークンやそれによって保護されるリソースに対する意図的な攻撃の他, 適切なセキュリティ対策が施されていない場合に起こりうるセキュリティリスクも含む.
        各脅威はプロトコル仕様の構造に基づいて整理され, デベロッパーが実装時に参照しやすく考慮されている.
        例えば, アクセスを許可する際の脅威や各grant typeそれぞれに固有の脅威, リソースサーバーに関わる脅威などが, 該当する章・節にまとめて紹介されている.
      </t>
      <!--
      <t>This document gives additional security considerations for OAuth,
      beyond those in the OAuth specification, based on a comprehensive threat
      model for the OAuth 2.0 protocol <xref target="RFC6749"></xref>.
      It contains the following content:<list style="symbols">

          <t>Documents any assumptions and scope considered when creating the
          threat model.</t>

          <t>Describes the security features built into the OAuth protocol
          and how they are intended to thwart attacks.</t>

          <t>Gives a comprehensive threat model for OAuth and describes the
          respective countermeasures to thwart those threats.</t>
        </list>Threats include any intentional attacks on OAuth tokens and
      resources protected by OAuth tokens, as well as security risks introduced
      if the proper security measures are not put in place. Threats are
      structured along the lines of the protocol structure to help development
      teams implement each part of the protocol securely, for example, all
      threats for granting access, or all threats for a particular grant type,
      or all threats for protecting the resource server.</t>
      -->

      <t>
        注)
        本ドキュメントはそれぞれの脅威の発生確率や具体的なリスクについては述べない.
        そういった項目は, 実装やサービス内容に大きく左右されるためである.
        本ドキュメントは抽象的なレベルでの議論を行うが, ここで述べられる情報は実装固有の脅威モデルを考慮する際の基礎となるであろう.
        実装者には, 抽象的な脅威モデルを実際の実装にあてはめ, リスク分析を行うことが求められる.
        なお本ドキュメントはOAuth 2.0仕様本体を対象としており, 本ドキュメント執筆現在仕様策定が進んでいるクライアント登録やディスカバリーなどの拡張仕様については考慮しない.
      </t>
      <!--
      <t>Note: This document cannot assess the probability or the risk
      associated with a particular threat because those aspects strongly
      depend on the particular application and deployment OAuth is used to
      protect. Similarly, impacts are given on a rather abstract level. But the
      information given here may serve as a foundation for deployment-specific
      threat models. Implementors may refine and detail the abstract threat
      model in order to account for the specific properties of their
      deployment and to come up with a risk analysis. As this document is
      based on the base OAuth 2.0 specification, it does not consider proposed
      extensions such as client registration or discovery, many of which are
      still under discussion.</t>
      -->
    </section>

    <section title="Overview">
      <t></t>

      <section title="Scope">
        <t>
          本ドキュメントで述べられるSecurity Considerationsは, <xref target="RFC6749"></xref> がサポートする, 特定のOAuthサーバーと紐づくクライアントのみを考慮する.
          こういった実装は以下のような特徴を持つ.
        </t>
        <!--
        <t>This security considerations document only considers clients bound
        to a particular deployment as supported by <xref
        target="RFC6749"></xref>. Such deployments have the
        following characteristics:</t>
        -->

        <t>
          <list style="symbols">
            <t>
              リソースサーバーURLは固定で実装時に既に周知されている.
              認可サーバーURLは固定もしくは事前に知ることができる.
            </t>
            <t>
              トークンのscopeに指定される値 (アプリケーションURLやmethodなど) は, 実装時に周知されている.
            </t>
            <t>
              クライアント登録は現在のCore仕様の範囲外である.
              従って本ドキュメントはstatic/dynamicに関わらず幅広いクライアント登録方法を想定する.
            </t>
          </list>
          また以下の項目は対象外とする.
        </t>

        <!--
        <t><list style="symbols">
            <t>Resource server URLs are static and well-known at development
            time; authorization server URLs can be static or discovered.</t>

            <t>Token scope values (e.g., applicable URLs and methods) are
            well-known at development time.</t>

            <t>Client registration is out of
            scope of the current core specification.  Therefore, this document assumes a broad
            variety of options, from static registration during development
            time to dynamic registration at runtime.</t>
          </list>The following are considered out of scope:</t>
        -->

        <t>
          <list style="symbols">
            <t>
              認可サーバー・リソースサーバー間のコミュニケーション.
            </t>
            <t>
              トークンフォーマット.
            </t>
            <t>
              認可サーバーがユーザーを認証する方式.
              ただしリソースオーナーパスワードクレデンシャルグラント (<xref target="RFC6749"></xref> Section 4.3 参照) については対象とする.
            </t>
            <t>
              アサーション取得メカニズムおよび不正なアサーションによってもたらされる攻撃.
            </t>
            <t>
              特定のOAuthサーバーと紐づけられていないクライアント.
              例えばPortable Contacts API <xref target="Portable-Contacts"></xref> 経由でコンタクトリストにアクセスすることができるメールクライアントなど.
              このようなクライアントは事前に特定のOAuthサーバーと紐づけておくことはできず, dynamicにOAuthプロトコルの各URLを検知 (discover) する必要がある.
            </t>
          </list>
        </t>

        <!--
        <t><list style="symbols">
            <t>Communication between the authorization server and resource
            server.</t>

            <t>Token formats.</t>

            <t>Except for the resource owner password credentials grant type
            (see <xref target="RFC6749"></xref>, Section 4.3), the
            mechanism used by authorization servers to authenticate the
            user.</t>

            <t>Mechanism by which a user obtained an assertion and any
            resulting attacks mounted as a result of the assertion being
            false.</t>

            <t>Clients not bound to a specific deployment: An example could be
            a mail client with support for contact list access via the
            portable contacts API (see <xref
            target="Portable-Contacts"></xref>). Such clients cannot be
            registered upfront with a particular deployment and should
            dynamically discover the URLs relevant for the OAuth protocol.</t>
          </list></t>
        -->
      </section>

      <section title="Attack Assumptions">
        <t>
          攻撃者とリソースに関して, 以下の想定を置く.
        </t>
        <!--
        <t>The following assumptions relate to an attacker and resources
        available to an attacker.  It is assumed that:</t>
        -->

        <t>
          <list style="symbols">
            <t>
              攻撃者はクライアントと認可サーバー, およびクライアントとリソースサーバーの間のネットワークに直接アクセス可能であり, そこでのいかなる通信も盗聴できる状態にある.
              ただし認可サーバー・リソースサーバー間の通信へはアクセスできないものとする.
            </t>
            <t>
              攻撃者が攻撃に利用するリソースに制限は無い物とする.
            </t>
            <t>
              OAuthプロトコルに関与する3者のうちの2者が, 共謀して残る1者に対する攻撃を行う可能性があるものとする.
              例えば, クライアントと認可サーバーが攻撃者の管理下にあり, リソースアクセスを得るためユーザーを騙すため共謀するケースなどが考えられる.
            </t>
          </list>
        </t>

        <!--
        <t><list style="symbols">
            <t>the attacker has full access to the network
            between the client and authorization servers and the client and
            the resource server, respectively. The attacker may eavesdrop on
            any communications between those parties. He is not assumed to
            have access to communication between the authorization server
            and resource server.</t>

            <t>an attacker has unlimited resources to mount an attack.</t>

            <t>two of the three parties involved in the OAuth
            protocol may collude to mount an attack against the 3rd party. For
            example, the client and authorization server may be under control
            of an attacker and collude to trick a user to gain access to
            resources.</t>
          </list></t>
        -->
      </section>

      <section title="Architectural Assumptions">
        <t>
          本セクションではセキュリティ上重要なデータに関して, OAuthの各エンティティが持ちうる機能, 制限および設計上のオプションについて仮定する.
          これらは脅威解析における基礎となる.
        </t>
        <!--
        <t>This section documents assumptions about the features,
        limitations, and design options of the different entities of an OAuth
        deployment along with the security-sensitive data elements managed by
        those entities. These assumptions are the foundation of the threat
        analysis.</t>
        -->

        <t>
          OAuthプロトコルはある程度実装に自由度を残している.
          Core仕様は認可サーバーとリソースサーバーの基本的なコンセプトを定めている.
          これら両サーバーは単一のエンティティとして実装されることもあれば, 分散した複数のエンティティとして実装される場合もある.
          後者の典型例としては, 複数のサービスを提供している事業者が, 単一の認証・認可サービスを, 特にミドルウェアレベルで共通に用いるケースなどがある.
        </t>
        <!--
        <t>The OAuth protocol leaves deployments with a certain degree of
        freedom regarding how to implement and apply the standard. The core
        specification defines the core concepts of an authorization server and
        a resource server. Both servers can be implemented in the same server
        entity, or they may also be different entities. The latter is typically
        the case for multi-service providers with a single authentication and
        authorization system and is more typical in middleware
        architectures.</t>
        -->

        <section title="Authorization Servers">
          <t>
            認可サーバーでは, 以下のデータが保存されているかアクセス可能な状態にある.
          </t>
          <!--
          <t>The following data elements are stored or accessible on the
          authorization server:</t>
          -->

          <t>
            <list style="symbols">
              <t>
                ユーザーネームとパスワード
              </t>
              <t>
                クライアントIDとクライアントシークレット
              </t>
              <t>
                特定のクライアントと紐づけられたリフレッシュトークン
              </t>
              <t>
                特定のクライアントと紐づけられたアクセストークン
                (Handleベースデザイン <xref target="section_tokens"></xref> を用いる場合)
              </t>
              <t>
                HTTPS 証明書/鍵
              </t>
              <t>
                認可プロセスごとの "redirect_uri", "client_id" および認可コード "code"
                (Handleベースデザイン <xref target="section_tokens"></xref> を用いる場合)
              </t>
            </list>
            (訳注: Assertionタイプのトークンを用いる場合, redirect_uri や client_id などがトークン自体に含まれており, それらが認可サーバー上には保存されていない場合もある)
          </t>

          <!--
          <t><list style="symbols">
              <t>usernames and passwords</t>

              <t>client ids and secrets</t>

              <t>client-specific refresh tokens</t>

              <t>client-specific access tokens (in the case of
              handle-based design; see <xref target="section_tokens"></xref>)</t>

              <t>HTTPS certificate/key</t>

              <t>per-authorization process (in the case of
              handle-based design; <xref target="section_tokens"></xref>):
              "redirect_uri", "client_id", authorization "code"</t>
            </list></t>
          -->
        </section>

        <section title="Resource Server">
          <t>
            リソースサーバーでは, 以下のデータが保存されているかアクセス可能な状態にある.
          </t>
          <!--
          <t>The following data elements are stored or accessible on the
          resource server:</t>
          -->

          <t>
            <list style="symbols">
              <t>
                ユーザーデータ (詳細はプロトコルの範囲外)
              </t>
              <t>
                HTTPS 証明書/鍵
              </t>
              <t>
                認可サーバークレデンシャルもしくは認可サーバー共有鍵/公開鍵
                (前者はHandleベースデザイン <xref target="section_tokens"></xref> を用いる場合, 後者はAssertionベースデザイン <xref target="section_tokens"></xref> を用いる場合)
              </t>
              <t>
                (リクエストごとの) アクセストークン
              </t>
            </list>
            リソースサーバーはリフレッシュトークン, ユーザーパスワードおよびクライアントシークレットは知らないものとする.
          </t>
          <!--
          <t><list style="symbols">
              <t>user data (out of scope)</t>

              <t>HTTPS certificate/key</t>

              <t>either authorization server credentials (handle-based design;
              see <xref target="section_tokens"></xref>) or authorization
              server shared secret/public key (assertion-based design;
              see <xref target="section_tokens"></xref>)</t>

              <t>access tokens (per request)</t>
            </list>

          It is assumed that a resource server has no knowledge of
          refresh tokens, user passwords, or client secrets.</t>
          -->
        </section>

        <section title="Client">
          <t>
            OAuthでは, クライアントとはリソースオーナーの代理として, リソースオーナーの認可のもとで保護リソースへのアクセスを行うアプリケーションである.
            Webアプリケーション, ユーザーエージェントベースアプリケーション, ネイティブアプリケーションといったクライアントタイプごとに, 実装上およびセキュリティ上の特徴は異なる.
            クライアントタイプとそのプロフィールについては <xref target="RFC6749"></xref> Section 2.1 に定義されている.
          </t>
          <!--
          <t>In OAuth, a client is an application making protected resource
          requests on behalf of the resource owner and with its authorization.
          There are different types of clients with different implementation
          and security characteristics, such as web, user-agent-based, and
          native applications. A full definition of the different client types
          and profiles is given in <xref target="RFC6749"></xref>,
          Section 2.1.</t>
          -->

          <t>
            クライアントでは, 以下のデータが保存されているかアクセス可能な状態にある.
          </t>
          <!--
          <t>The following data elements are stored or accessible on the
          client:</t>
          -->

          <t>
            <list style="symbols">
              <t>
                クライアントID (およびクライアントシークレットもしくはそれに相当する何らかのクライアントクレデンシャル)
              </t>
              <t>
                エンドユーザーごと, もしくはその他のセキュリティコンテキストや委譲コンテキストごとの, 1つ以上のリフレッシュトークン (長期間) およびアクセストークン (短期間)
              </t>
              <t>
                信頼された証明機関の証明書 (Trusted CA certificates, HTTPS)
              </t>
              <t>
                認可プロセスごとの "redirect_uri", 認可コード "code"
              </t>
            </list>
          </t>
          <!--
          <t><list style="symbols">
              <t>client id (and client secret or corresponding client
              credential)</t>

              <t>one or more refresh tokens (persistent) and access tokens
              (transient) per end user or other security-context or delegation
              context</t>

              <t>trusted certification authority (CA) certificates (HTTPS)</t>

              <t>per-authorization process: "redirect_uri",
              authorization "code"</t>
            </list></t>
          -->
        </section>
      </section>
    </section>

    <section anchor="sec_features" title="Security Features">
      <t>
        OAuth 2.0には, ある程度プロトコルレベルで攻撃やセキュリティリスクに対する対策が施されている.
      </t>
      <!--
      <t>These are some of the security features that have been built into
      the OAuth 2.0 protocol to mitigate attacks and security issues.</t>
      -->

      <section anchor="section_tokens" title="Tokens">
        <t>
          OAuthは広範囲に渡っていろいろな種類のトークン (アクセストークン, リフレッシュトークン, 認可コード) を用いる.
          トークンの表現方法としては以下の2通りがある.
        </t>
        <!--
        <t>OAuth makes extensive use of many kinds of tokens (access tokens,
        refresh tokens, authorization "codes"). The information content of a
        token can be represented in two ways, as follows:</t>
        -->

        <t>
          <list style="hanging">
            <t hangText="Handle (or artifact)">
              "handle" ("artifact" とも呼ばれる) とは, 認可サーバー内部のデータ構造に対するある種の参照である.
              内部データ構造には, ユーザーID (UID) やスコープなどのトークンの属性が含まれる.
              handleを用いることで, トークン無効化処理を簡略化し, 暗号化メカニズムを不要にすることができる.
              一方でhandleを用いると, 検証およびトークン内容取得のために, 発行者と消費者 (認可サーバーとリソースサーバーなど) の間の通信が必須となる.
              これはトークンの発行者と利用者 (認可サーバーとリソースサーバーなど) が異なるエンティティである場合, パフォーマンスやスケーラビリティの点で不利である.
              したがってhandleは主に発行者と消費者 (認可サーバーとリソースサーバーなど) が同一エンティティである場合に用いられることになるであろう.
              handleトークンはしばしば "opaque" トークンと呼ばれるが, これはリソースサーバーがそのトークン自体を解読する必要がなく, 単なるトークン文字列として利用するのみだからである.
            </t>

            <t hangText="Assertion (aka self-contained token)">
              assertionとはパース可能なトークンである.
              assertionは典型的には有効期間, 発行対象 (audience) を持ち, 改竄防止および発行者認証のため電子署名が付けられる.
              SAML assertion <xref target="OASIS.saml-core-2.0-os"></xref> や Kerberos ticket <xref target="RFC4120"></xref> が例として挙げられる.
              assertionは典型的にはリソースサーバーに直接検証される.
              このときリソースサーバーと認可サーバーの間で通信を行う必要はない.
              これはトークンの発行者と利用者 (認可サーバーとリソースサーバーなど) が異なるエンティティである場合, パフォーマンスやスケーラビリティの点で有利である.
              ただしassertionを用いた場合, トークン無効化の実装はhandleを用いた場合より困難である.
            </t>
          </list>
          リソースサーバーへのリクエストにトークンを利用する場合, 以下の2つの方法を取りうる.
        </t>
        <!--
        <t><list style="hanging">
            <t hangText="Handle (or artifact)">A 'handle' is a reference
            to some internal
            data structure within the authorization server; the internal data
            structure contains the attributes of the token, such as user id
            (UID),
            scope, etc. Handles enable simple revocation and do not require
            cryptographic mechanisms to protect token content from being
            modified. On the other hand, handles require communication between
            the issuing and consuming entity (e.g., the authorization server
            and resource server) in order to validate the token and
            obtain token-bound data. This communication might have a
            negative impact on
            performance and scalability if both entities reside on different
            systems. Handles are therefore typically used if the issuing and
            consuming entity are the same. A 'handle' token is often referred
            to as an 'opaque' token because the resource server does not need
            to be able to interpret the token directly; it simply uses the
            token.</t>

            <t hangText="Assertion (aka self-contained token)">An
            assertion is a parseable token.
            An assertion typically has a duration, has an audience, and
            is digitally signed in order to ensure data integrity and origin
            authentication. It contains information about the user and the
            client. Examples of assertion formats are
            Security Assertion Markup Language (SAML) assertions <xref
            target="OASIS.saml-core-2.0-os"> </xref> and Kerberos tickets
            <xref target="RFC4120"></xref>. Assertions can typically be
            directly validated and used by a resource server without
            interactions with the authorization server. This results in
            better performance and scalability in deployments where the
            issuing and consuming entities reside on different systems.
            Implementing token revocation is more difficult with
            assertions than with handles.</t>
          </list>Tokens can be used in two ways to invoke requests on resource
        servers, as follows:</t>
        -->

        <t>
          <list style="hanging">
            <t hangText="bearer token">
              bearer tokenとは, それを受け取ったいかなるクライアントにも利用可能なトークンである (<xref target="RFC6750"></xref>).
              トークンを所有していることのみがその利用条件であるため, エンドポイント間での通信がセキュアに保たれ, 許可されたエンドポイントのみがそのトークンにアクセスできる状態を担保することが重要である.
              bearer tokenは, クライアントアプリケーションにとっては (proof tokenのように) 利用に際して特別な処理を行う必要がないため便利である.
              bearer tokenはWeb上で single-sign-on (SSO) を行う際ブラウザで用いられるcookieと類似の特徴を持つ.
            </t>

            <t hangText="proof token">
              proof tokenは特定のクライアントにのみ利用可能なトークンである.
              クライアントは, トークン利用に際して毎回自身がトークン利用可能な主体であることを証明するために何らかの処理を行う必要がある.
              クライアントにリクエスト内容に対して特定のトークンと紐づいた秘密鍵を用いて電子署名を要求する, MACタイプのアクセストークン (<xref target="OAuth-HTTP-MAC"></xref>) などがその例である.
            </t>
          </list>
        </t>
        <!--
        <t><list style="hanging">
            <t hangText="bearer token">A 'bearer token' is a token that can be
            used by any client who has received the token (e.g., <xref
            target="RFC6750"></xref>). Because mere
            possession is enough to use the token, it is important that
            communication between endpoints be secured to ensure that only
            authorized endpoints may capture the token. The bearer token is
            convenient for client applications, as it does not require them to
            do anything to use them (such as a proof of identity). Bearer
            tokens have similar characteristics to web single-sign-on (SSO)
            cookies used in browsers.</t>

            <t hangText="proof token">A 'proof token' is a token that can only
            be used by a specific client. Each use of the token requires the
            client to perform some action that proves that it is the
            authorized user of the token. Examples of this are
            MAC-type access tokens, which
            require the client to digitally sign the resource request with a
            secret corresponding to the particular token sent with the
            request (e.g., <xref target="OAuth-HTTP-MAC"></xref>).</t>
          </list></t>
        -->

        <section title="Scope">
          <t>
            scopeは, 特定のトークンに紐づき, リソースサーバー, リソース, およびリソースへの操作に関するアクセス認可を示す.
            scopeは, OAuthにおいてアクセストークンの持つ権限を明示的に示す手段となる.
            scopeは, 認可サーバーとエンドユーザーが, 比較的セキュアでなく信頼度の低いと考えられるOAuthクライアントに対して, リソースへのアクセス権限を制限・制御するために用いられる.
            クライアントは必要に応じてトークンの権限を狭めるためだけにscopeを用いることができる.
            (例: セキュアでないチャネルを通じてトークンが送信される際, 潜在的リスクを軽減するためなど)
            典型的には, scopeはトークンの有効期間 (lifetime) 制限と併用され, 補完関係にある.
          </t>
          <!--
          <t>A scope represents the access authorization associated with a
          particular token with respect to resource servers, resources, and
          methods on those resources. Scopes are the OAuth way to explicitly
          manage the power associated with an access token. A scope can be
          controlled by the authorization server and/or the end user in order
          to limit access to resources for OAuth clients that these parties
          deem less secure or trustworthy. Optionally, the client can request
          the scope to apply to the token but only for a lesser scope than
          would otherwise be granted, e.g., to reduce the potential impact
          if this token is sent over non-secure channels. A scope is typically
          complemented by a restriction on a token's lifetime.</t>
          -->
        </section>

        <section title="Limited Access Token Lifetime">
          <t>
            "expires_in" というプロトコルパラメーターによって, 認可サーバーはアクセストークンの有効期間 (lifetime) を制限し, そのlifetimeに関する情報をクライアントに通知することができる.
            (lifetimeは, ユーザーの意思によって行われたり, 認可サーバーのポリシーによって決定される)
            このメカニズムにより, 認可サーバーが比較的セキュアでないと見なすOAuthクライアントに対して有効期間の短いトークンを発行したり, セキュアでないチャネルを利用する際に同様に有効期間を短くしたりすることができる.
          </t>
          <!--
          <t>The protocol parameter "expires_in" allows an authorization server
          (based on its policies or on behalf of the end user) to limit the
          lifetime of an access token and to pass this information to the
          client. This mechanism can be used to issue short-lived tokens to
          OAuth clients that the authorization server deems less secure, or
          where sending tokens over non-secure channels.</t>
          -->
        </section>
      </section>

      <section title="Access Token">
        <t>
          アクセストークンはクライアントがリソースにアクセスする際に用いられる.
          アクセストークンには, 典型的には (数分〜数時間程度の) セッションのlifetimeをカバーする程度の短い有効期間が設定される.
          アクセストークンはリフレッシュトークンを用いることでリフレッシュ可能である.
          有効期間の短いアクセストークンとリフレッシュトークンを併用することで, 明示的な無効化処理無しにアクセストークンの無効化が行われる可能性を高めることができる.
        </t>
        <!--
        <t>An access token is used by a client to access a resource. Access
        tokens typically have short life spans (minutes or hours) that cover
        typical session lifetimes. An access token may be refreshed through
        the use of a refresh token. The short lifespan of an access token, in
        combination with the usage of refresh tokens, enables the possibility
        of passive revocation of access authorization on the expiry of the
        current access token.</t>
        -->
      </section>

      <section title="Refresh Token">
        <t>
          リフレッシュトークンは, 特定のクライアントに対する長期間有効な認可情報を示す.
          このトークンはクライアント・認可サーバー間でのみ送信される.
          クライアントはこのトークンを使って新しい ("refresh" された) アクセストークンを取得することができる.
        </t>
        <!--
        <t>A refresh token represents a long-lasting authorization of a
        certain client to access resources on behalf of a resource owner. Such
        tokens are exchanged between the client and authorization server only.
        Clients use this kind of token to obtain ("refresh") new access tokens
        used for resource server invocations.</t>
        -->

        <t>
          リフレッシュトークンによって, アクセストークンの有効期間を短く保ちつつ, ユーザーの関与無しに長期間有効なアクセス権限を維持することができる.
          リフレッシュトークンは, (分散環境など) リソースサーバーと認可サーバーが同一エンティティでない場合に1つのアドバンテージをもたらす.
          認可サーバーがリフレッシュトークンを無効化するだけで, 発行済アクセストークンが期限切れになった時点ですべてのアクセス権限を無効化することができるのである.
          この際, アクセストークンの有効期間を短く保つことは, タイムリーなアクセス権限無効化の為に重要なポイントとなる.
          (訳注: アクセストークンが複数のリソースサーバーに分散してしまっている状況で, それを確実に無効化するのは面倒な処理である)
        </t>
        <!--
        <t>A refresh token, coupled with a short access token lifetime, can be
        used to grant longer access to resources without involving end-user
        authorization. This offers an advantage where resource servers and
        authorization servers are not the same entity, e.g., in a distributed
        environment, as the refresh token is always exchanged at the
        authorization server. The authorization server can revoke the refresh
        token at any time, causing the granted access to be revoked once the
        current access token expires. Because of this, a short access token
        lifetime is important if timely revocation is a high priority.</t>
        -->

        <t>
          リフレッシュトークンは, クライアント識別子および認可リクエストを行った特定のクライアントインスタンスに紐づいたsecretでもあり, リソースオーナー認可そのものを示すものでもある.
          このことは以下の認可プロセスによって保証される.
        </t>
        <!--
        <t>The refresh token is also a secret bound to the client identifier
        and client instance that originally requested the authorization; the
        refresh token also represents the original resource owner grant.
        This is ensured by the authorization process as follows:</t>
        -->

        <t>
          <list style="numbers">
            <t>
              リソースオーナーとユーザーエージェントがセキュアに認可コードをクライアントインスタンスに送付する.
            </t>
            <t>
              クライアントは即座にセキュアチャネルを通じてそれを認可サーバーに送り, 受け取ったリフレッシュトークンをセキュアに保存する.
            </t>
            <t>
              クライアントは常にリフレッシュトークンをセキュアチャネルを通じて送信し, アクセストークンを取得する.
              (この際オプションで新たなリフレッシュトークンを得る)
            </t>
          </list>
          以上により, クライアントが特定のトークンの秘匿性を維持する限り, リフレッシュトークンはクライアント自身を認証するためにも用いることができる.
        </t>
        <!--
        <t><list style="numbers">
            <t>The resource owner and user agent safely deliver the
            authorization "code" to the client instance in the first place.</t>

            <t>The client uses it immediately in secure transport-level
            communications to the authorization server and then securely
            stores the long-lived refresh token.</t>

            <t>The client always uses the refresh token in secure
            transport-level communications to the authorization server to get
            an access token (and optionally roll over the refresh token).</t>
          </list>So, as long as the confidentiality of the particular token can
        be ensured by the client, a refresh token can also be used as an
        alternative means to authenticate the client instance itself.</t>
        -->
      </section>

      <section title="Authorization &quot;code&quot;">
        <t>
          認可コード ("code") はエンドユーザー認可の取得に成功した結果として発行され, クライアントがアクセストークンおよびリフレッシュトークンを取得する際の中間物として動作する.
          認可コードは以下の2つの目的で, トークンの代わりにクライアントのリダイレクトURIに送信される.
        </t>
        <!--
        <t>An authorization "code" represents the intermediate result of a
        successful end-user authorization process and is used by the client to
        obtain access and refresh tokens. Authorization "codes" are sent to the
        client's redirect URI instead of tokens for two purposes:</t>
        -->

        <t>
          <list style="numbers">
            <t>
              ブラウザベースフローでは, プロトコルパラメーターは潜在的攻撃者にアクセス可能な状態になる.
              ブラウザキャッシュやログファイルなどがその経路となりうる.
              また攻撃者によって異なる値に置き換えられる可能性もある.
              これらのリスクを軽減するため, トークンの代わりに有効期間の短い認可コードを送信し, それをよりセキュアなクライアント・認可サーバー間のダイレクト通信を通じてトークンと交換するのである.
            </t>
            <t>
              クライアント認証は, ダイレクト通信ではない認可リクエストより, ダイレクト通信によって行う方が遥かに簡単である.
              認可リクエスト時にクライアント認証を行うには, 電子署名が必要となる.
            </t>
          </list>
        </t>
        <!--
        <t><list style="numbers">
            <t>Browser-based flows expose protocol parameters to potential
            attackers via URI query parameters (HTTP referrer), the browser
            cache, or log file entries, and could be replayed. In order to
            reduce this threat, short-lived authorization "codes" are passed
            instead of tokens and exchanged for tokens over a more secure
            direct connection between the client and the authorization
            server.</t>

            <t>It is much simpler to authenticate clients during the direct
            request between the client and the authorization server than in the
            context of the indirect authorization request. The latter would
            require digital signatures.</t>
          </list></t>
          -->
      </section>

      <section title="Redirect URI">
        <t>
          リダイレクトURIを用いることで, 不正クライアントの検知やフィッシング攻撃の防止に役立つ.
          実際に認可リクエスト時に用いられたリダイレクトURIは, 認可コードをトークンと交換する際に提示され検証される.
          これにより認可コードがリダイレクタを通じて偽のクライアントに漏洩した際にも, 攻撃を防ぐことができる.
          認可サーバーはパブリッククライアントおよびimplicitグラントタイプを利用するコンフィデンシャルクライアントに対しては, リダイレクトURIの事前登録を必須とし, 認可リクエスト時に指定されるリダイレクトURIを事前登録済みのそれと比較検証するべきである.
        </t>
        <!--
        <t>A redirect URI helps to detect malicious clients and prevents
        phishing attacks from clients attempting to trick the user into
        believing the phisher is the client. The value of the actual
        redirect URI used in the authorization request has to be presented
        and is verified when an authorization "code" is exchanged for tokens.
        This helps to prevent attacks where the authorization "code" is
        revealed through redirectors and counterfeit web application clients.
        The authorization server should require public clients and
        confidential clients using the implicit grant type to pre-register
        their redirect URIs and validate against the registered
        redirect URI in the authorization request.</t>
        -->
      </section>

      <section title="&quot;state&quot; Parameter">
        <t>
          stateパラメーターは, リクエストとそれに対するコールバックを紐づけCSRF攻撃 (<xref target="section_csrf"></xref>) を防止するために用いられる.
          CSRF攻撃においては, 攻撃者は自身のリソースへのアクセスを許可し, 攻撃者に対して発行されたトークンを含むリダイレクトリクエストをユーザーに実行させる.
          stateパラメーターはユーザーエージェントと紐付けられ, ユーザーエージェントはそれをクライアントおよびユーザーエージェントのみにアクセス可能な場所に保存する.
          (例: same-originポリシーによって保護された場所)
        </t>
        <!--
        <t>The "state" parameter is used to link requests and callbacks to
        prevent cross-site request forgery attacks (see <xref
        target="section_csrf"></xref>) where an attacker authorizes access to
        his own resources and then tricks a user into following a redirect
        with the attacker's token. This parameter should bind to the
        authenticated state in a user agent and, as per the core OAuth spec,
        the user agent must be capable of keeping it in a location accessible
        only by the client and user agent, i.e., protected by same-origin
        policy.</t>
        -->
      </section>

      <section title="Client Identifier">
        <t>
          認証プロトコルは一般的にエンドユーザーの代理として動作するソフトウェアコンポーネントの素性に関しては考慮しない.
          しかしながらOAuthはそれを考慮し, 認可委譲におけるセキュリティレベルを向上している.
          OAuthクライアントがユーザーが不在な状況でも動作しうるとうことも, その理由である.
        </t>
        <!--
        <t>Authentication protocols have typically not taken into account the
        identity of the software component acting on behalf of the end user.
        OAuth does this in order to increase the security level in delegated
        authorization scenarios and because the client will be able to act
        without the user being present.</t>
        -->

        <t>
          OAuthでは以下のように, 一連のリクエストが同一クライアントによって実行されているかを照合するため, クライアント識別子を用いる.
        </t>
        <!--
        <t>OAuth uses the client identifier to collate associated requests to
        the same originator, such as</t>
        -->

        <t>
          <list style="symbols">
            <t>
              特定エンドユーザーの認可プロセスと, それに続くトークンエンドポイントにおける認可コードとトークンの交換リクエスト
            </t>
            <t>
              エンドユーザーによる特定クライアントへの認可およびその際に発行された初期のトークンと, 該当クライアントがその後ユーザーの同意無しに取得したトークン
              (初回以降の認可自動承認プロセスを意味する)
            </t>
          </list>
          クライアント識別子は, 認可サーバーがユーザーに同意を求める際に, そのクライアントに関する情報を表示するためにも用いられる.
          さらに特定のクライアントからのリクエスト数を制限したり, リクエストに対して課金を行う際に用いられることもある.
          サーバーログファイルなどで異なるクライアントからのアクセスを区別する際に用いることもできるであろう.
        </t>
        <!--
        <t><list style="symbols">
            <t>a particular end-user authorization process and the
            corresponding request on the token's endpoint to exchange the
            authorization "code" for tokens, or</t>

            <t>the initial authorization and issuance of a token by an
            end user to a particular client, and subsequent requests by this
            client to obtain tokens without user consent (automatic processing
            of repeated authorizations)</t>
          </list>This identifier may also be used by the authorization server
        to display relevant registration information to a user when requesting
        consent for a scope requested by a particular client. The client
        identifier may be used to limit the number of requests for a particular
        client or to charge the client per request. It may furthermore be
        useful to differentiate access by different clients, e.g., in server
        log files.</t>
        -->

        <t>
          OAuthは, クライアントが認可サーバーに対して自身を認証する能力に基づいて, コンフィデンシャルとパブリックという2つのクライアントタイプを定義している.
          (例: クライアントクレデンシャルの秘匿性を保持できるかどうかなど)
          コンフィデンシャルクライアントはクライアントクレデンシャル (クライアント識別子と紐づいたクライアントシークレットなど) を秘匿に保つことができる, もしくはクライアントアサーション (SAML参照) や鍵暗号法などの手段によりセキュアにクライアント認証を行うことができる.
          なお後者のクライアントアサーション (SAML参照) や鍵暗号法を用いた手段の方が, よりセキュアであると考えられる.
        </t>
        <!--
        <t>OAuth defines two client types, confidential and public, based on
        their ability to authenticate with the authorization server (i.e.,
        ability to maintain the confidentiality of their client credentials).
        Confidential clients are capable of maintaining the confidentiality of
        client credentials (i.e., a client secret associated with the client
        identifier) or capable of secure client authentication using other
        means, such as a client assertion (e.g., SAML) or key cryptography. The
        latter is considered more secure.</t>
        -->

        <t>
          認可サーバーはクライアントがシークレットを秘匿に保てるかどうか, セキュアな認証方式を利用可能かどうかなどを特定すべきである.
          ただしその代わりにエンドユーザーがクライアントの素性を検証することも可能である.
          (信頼できるアプリケーションのみをインストールするなど)
          リダイレクトURIは, クレデンシャルを偽のクライアントに送信することを防止するために用いられる場合もあるが, クライアントの素性を検証するために用いることはできない.
        </t>
        <!--
        <t>The authorization server should determine whether the client is
        capable of keeping its secret confidential or using secure
        authentication. Alternatively, the end user can verify the identity of
        the client, e.g., by only installing trusted applications. The
        redirect URI can be used to prevent the delivery of credentials to a
        counterfeit client after obtaining end-user authorization in some
        cases but can't be used to verify the client identifier.</t>
        -->

        <t>
          クライアントはクライアントタイプ, プロフィールおよびデプロイモデルによって以下のように分類できる.
          (native, webアプリケーションなど, <xref target="RFC6749"></xref> Section 9参照)
        </t>
        <!--
        <t>Clients can be categorized as follows based on the client type,
        profile (e.g., native vs. web application; see <xref
        target="RFC6749"></xref>, Section&nbsp;9), and deployment model:</t>
        -->

        <t>
          <list style="hanging">
            <t hangText="Deployment-independent &quot;client_id&quot; with pre-registered &quot;redirect_uri&quot; and without &quot;client_secret&quot;">
              このケースでは, クライアント識別子は同一ソフトウェアの複数インスタンスに共通して利用される.
              このようなクライアント識別子はエンドユーザーの関与無しには検証できない.
              ネイティブアプリケーションにおいては, ユーザーにクライアントのメタ情報を提示し, ログファイル中でクライアントを区別するには十分である.
              このクライアント識別子に紐づくアクセス権限の無効化は, 同一ソフトウェアの全インスタンスに影響する.
            </t>

            <t hangText="Deployment-independent &quot;client_id&quot; with pre-registered &quot;redirect_uri&quot; and with &quot;client_secret&quot;">
              これはネイティブアプリケーションのためだけのオプションである.
              この分類は, クライアントシークレットが適切に保護されないため推奨されない. (<xref target="ObtainClientSecrets"></xref> 参照)
              セキュリティ上の弱点のため, このようなクライアント識別子は上記のシークレットを持たないクライアントと同レベルの信頼度となる.
              アクセス権減の無効化は, 同一ソフトウェアの全インスタンスに影響する.
            </t>

            <t hangText="Deployment-specific &quot;client_id&quot; with pre-registered &quot;redirect_uri&quot; and with &quot;client_secret&quot;">
              クライアント登録プロセスにおいて, リダイレクトURI, WebサイトURL, Webサイト名および連絡先などのクライアント属性の検証が行われることが保証される.
              このようなクライアントは上記のすべてのユースケースで利用可能である.
              このレベルは手動もしくはユーザーごとに固有の登録プロセスを伴うWebアプリケーションで実現される.
              ネイティブアプリケーションでこのレベルを実現するのは非常に困難である.
              ただし, アプリケーションのインストールが管理者によって行われ, 管理者によってクライアントの真正性が検証されているか, (アプリケーションマーケットプロバイダなどにより) end-to-endで単一エンティティによってデバイスインストールごとにクライアントクレデンシャルの生成が行われている場合には, ネイティブアプリケーションでもこのレベルを実現することは可能である.
              アクセス権限の無効化は, 単一のインスタンスにのみ影響する.
            </t>

            <t hangText="Deployment-specific &quot;client_id&quot; with &quot;client_secret&quot; without validated properties">
              このようなクライアントは認可サーバーによって特定トランザクション内のリクエスト (認可リクエスト, トークン発行リクエスト, リフレッシュトークン発行リクエストおよびアクセストークンリフレッシュリクエストなど) でのみ識別される.
              認可サーバーはいかなるクライアント属性をもエンドユーザーに保証することはできない.
              再認可時の自動認可処理は可能である.
              このようなクライアントクレデンシャルはクライアント属性の検証無しに自動的に生成可能である.
              これは特にネイティブアプリケーションには新たな選択肢となりうるであろう.
              アクセス権限の無効化は, 単一のインスタンスにのみ影響する.
            </t>
          </list>
        </t>

        <!--
        <t><list style="hanging">
            <t
            hangText="Deployment-independent &quot;client_id&quot; with pre-registered &quot;redirect_uri&quot; and without &quot;client_secret&quot;">Such
            an identifier is used by multiple installations of the same
            software package. The identifier of such a client can only be
            validated with the help of the end-user. This is a viable option
            for native applications in order to identify the client for the
            purpose of displaying meta information about the client to the
            user and to differentiate clients in log files. Revocation of the
            rights associated with such a client identifier will affect ALL
            deployments of the respective software.</t>

            <t
            hangText="Deployment-independent &quot;client_id&quot; with pre-registered &quot;redirect_uri&quot; and with &quot;client_secret&quot;">This
            is an option for native applications only, since web applications
            would require different redirect URIs. This category is not
            advisable because the client secret cannot be protected
            appropriately (see <xref target="ObtainClientSecrets"></xref>).
            Due to its security weaknesses, such client identities have the
            same trust level as deployment-independent clients without secrets.
            Revocation will affect ALL deployments.</t>

            <t
            hangText="Deployment-specific &quot;client_id&quot; with pre-registered &quot;redirect_uri&quot; and with &quot;client_secret&quot;">The
            client registration process ensures the validation of the client's
            properties, such as redirect URI, web site URL, web site name,
            and contacts. Such a client identifier can be utilized for all
            relevant use cases cited above. This level can be achieved for web
            applications in combination with a manual or user-bound
            registration process. Achieving this level for native applications
            is much more difficult. Either the installation of the application
            is conducted by an administrator, who validates the client's
            authenticity, or the process from validating the application to
            the installation of the application on the device and the creation
            of the client credentials is controlled end-to-end by a single
            entity (e.g., application market provider). Revocation will affect
            a single deployment only.</t>

            <t
            hangText="Deployment-specific &quot;client_id&quot; with &quot;client_secret&quot; without validated properties">Such
            a client can be recognized by the authorization server in
            transactions with subsequent requests (e.g., authorization and
            token issuance, refresh token issuance, and access token
            refreshment). The authorization server cannot assure any property
            of the client to end users. Automatic processing of
            re-authorizations could be allowed as well. Such client
            credentials can be generated automatically without any validation
            of client properties, which makes it another option, especially for
            native applications. Revocation will affect a single deployment
            only.</t>
          </list></t>
        -->
      </section>
    </section>

    <section anchor="threat_model" title="Threat Model">
      <t>
        このセクションではOAuth 2.0の脅威モデルを網羅的にまとめる.
        まず各脅威を, クライアント, 認可サーバーおよびリソースサーバーという, 攻撃対象となる各OAuthコンポーネントごとに分類する.
        続いてトークン取得と保護リソースへのアクセスという, フロー単位での分類を行う.
        それぞれに対する対抗策は <xref target="security_considerations"></xref> にまとめる.
      </t>
      <!--
      <t>This section gives a comprehensive threat model of OAuth 2.0. Threats
      are grouped first by attacks directed against an OAuth component, which
      are the client, authorization server, and resource server. Subsequently,
      they are grouped by flow, e.g., obtain token or access protected
      resources. Every countermeasure description refers to a detailed
      description in <xref target="security_considerations"></xref>.</t>
      -->

      <section title="Clients">
        <t>
          このセクションではOAuthクライアントに対する脅威について述べる.
        </t>
        <!--
        <t>This section describes possible threats directed to OAuth
        clients.</t>
        -->

        <section anchor="ObtainClientSecrets"
                 title="Threat: Obtaining Client Secrets">
          <t>
            攻撃者は以下のようにして, 特定のクライアントのシークレットにアクセスする可能性がある.
            (訳注: ここでの "access" は, secretが持つ権限に対するアクセスを意味し, あたかもそれを知っているかのようにして振る舞える, というニュアンス)
          </t>
          <!--
          <t>The attacker could try to get access to the secret of a
          particular client in order to:</t>
          -->

          <t>
            <list style="symbols">
              <t>
                リフレッシュトークンおよび認可コードに対するリプレイ攻撃を行なう.
              </t>
              <t>
                攻撃対象となるクライアントのclient_idを用いて該当クライアントになりすまし, トークンを取得する.
              </t>
            </list>
            このような攻撃により, 以下のような影響が発生しうる.
          </t>
          <!--
          <t><list style="symbols">
              <t>replay its refresh tokens and authorization "codes", or</t>

              <t>obtain tokens on behalf of the attacked client with the
              privileges of that "client_id" acting as an instance of the
              client.</t>
            </list>The resulting impact would be the following:</t>
          -->

          <t>
            <list style="symbols">
              <t>
                認可サーバーアクセス時のクライアント認証をバイパスされる.
              </t>
              <t>
                漏洩したリフレッシュトークンまたは認可コードを利用される.
              </t>
            </list>
            クライアントの種類によっては, 以下のような攻撃も考えられる.
          </t>
          <!--
          <t><list style="symbols">
              <t>Client authentication of access to the authorization server
              can be bypassed.</t>

              <t>Stolen refresh tokens or authorization "codes" can be
              replayed.</t>
            </list>Depending on the client category, the following attacks
          could be utilized to obtain the client secret.</t>
          -->

          <t>
            攻撃例: ソースコードまたはバイナリーからシークレットを取得
          </t>
          <!--
          <t>Attack: Obtain Secret From Source Code or Binary:</t>
          -->

          <t>
            これはどのようなクライアントに対しても起こりうる攻撃である.
            オープンソースプロジェクトでは, 公開レポジトリにあるソースコードから直接シークレットが漏洩する可能性がある.
            攻撃者にソースコードが渡らない状況でも, バイナリーからシークレットを取得することもできる.
            アプリケーション配布時にいかにシークレットの難読化を行っても, リバースエンジニアリングによってシークレットが漏洩する可能性は考慮すべきである.
          </t>
          <!--
          <t>This applies for all client types. For open source projects,
          secrets can be extracted directly from source code in their public
          repositories. Secrets can be extracted from application binaries
          just as easily when the published source is not available to the
          attacker. Even if an application takes significant measures to
          obfuscate secrets in their application distribution, one should
          consider that the secret can still be reverse-engineered by anyone
          with access to a complete functioning application bundle or
          binary.</t>
          -->

          <t>
            対抗策
          </t>
          <!--
          <t>Countermeasures:</t>
          -->

          <t>
            <list style="symbols">
              <t>
                パブリッククライアントやセキュリティポリシーを満たさないクライアントに対してシークレットを発行しない.
                (<xref target="dont_issue"></xref>)
              </t>
              <t>
                パブリッククライアントに対しては明示的なユーザーの同意を必須とする.
                (<xref target="forced_user_consent"></xref>)
              </t>
              <t>
                クライアントインスタンス単位でシークレットを発行する.
                (<xref target="depl_specific_secretes"></xref>)
              </t>
              <t>
                クライアントシークレットの無効化を行う.
                (<xref target="client_secret_revocation"></xref>)
              </t>
            </list>
          </t>
          <!--
          <t><list style="symbols">
              <t>Don't issue secrets to public clients or clients with
              inappropriate security policy
              (<xref target="dont_issue"></xref>).</t>

              <t>Require user consent for public clients
              (<xref target="forced_user_consent"></xref>).</t>

              <t>Use deployment-specific client secrets
              (<xref target="depl_specific_secretes"></xref>).</t>

              <t>Revoke client secrets
              (<xref target="client_secret_revocation"></xref>).</t>
            </list></t>
          -->

          <t>
            <vspace blankLines="1" />
            攻撃例: クライアントインスタンス単位で異なるシークレットを取得
          </t>
          <!--
          <t><vspace blankLines="1" />Attack: Obtain a Deployment-Specific
          Secret:</t>
          -->

          <t>
            攻撃者はクライアントインスタンス単位で異なるシークレットを, Webサイト (Webサーバー) や特定デバイス (ネイティブアプリケーション) から取得する可能性がある.
          </t>
          <!--
          <t>An attacker may try to obtain the secret from a client
          installation, either from a web site (web server) or a particular
          device (native application).</t>
          -->

          <t>
            対抗策:
          </t>
          <!--
          <t>Countermeasures:</t>
          -->

          <t>
            <list style="symbols">
              <t>
                Webサーバーの場合: (設定ファイルやデータベースなどに) 標準的な保護策を行う.
                (<xref target="std_web"></xref>)
              </t>
              <t>
                ネイティブアプリケーションの場合: シークレットをローカルのセキュアストレージに保存する.
                (<xref target="secure_storage"></xref>)
              </t>
              <t>
                クライアントシークレットを無効化する.
                (<xref target="client_secret_revocation"></xref>)
              </t>
            </list>
          </t>
          <!--
          <t><list style="symbols">
              <t>Web server: Apply standard web server protection measures
              (for config files and databases)
              (see <xref target="std_web"></xref>).</t>

              <t>Native applications: Store secrets in secure local storage
              (<xref target="secure_storage"></xref>).</t>

              <t>Revoke client secrets
              (<xref target="client_secret_revocation"></xref>).</t>
            </list></t>
          -->
        </section>

        <section title="Threat: Obtaining Refresh Tokens">
          <t>
            クライアントタイプによっては, 攻撃者にリフレッシュトークンが漏洩する経路としていくつかのパターンがある.
            各サブセクションではクライアントタイプごとにそれぞれの漏洩パターンおよび対抗策をまとめるが, まずは一般的な適用可能な対抗策について述べる.
          </t>
          <!--
          <t>Depending on the client type, there are different ways that
          refresh tokens may be revealed to an attacker. The following
          sub-sections give a more detailed description of the different
          attacks with respect to different client types and further
          specialized countermeasures. Before detailing those threats,
          here are some generally applicable countermeasures:</t>
          -->

          <t>
            <list style="symbols">
              <t>
                認可サーバーはリフレッシュリクエスト毎にリフレッシュトークンとクライアントIDの紐付けを検証する.
                (<xref target="binding_refresh_client_id"></xref>)
              </t>
              <t>
                トークンのscopeを制限する.
                (<xref target="limit_scope"></xref>)
              </t>
              <t>
                リフレッシュトークンを無効化する.
                (<xref target="refresh_revocation"></xref>)
              </t>
              <t>
                クライアントシークレットを無効化する.
                (<xref target="client_secret_revocation"></xref>)
              </t>
              <t>
                アクセストークンの不正利用が発覚した際に, リフレッシュトークンを置き換える.
                (<xref target="refresh_replace"></xref> の "Refresh Token Rotation" 参照)
              </t>
            </list>
          </t>
          <!--
          <t><list style="symbols">
              <t>The authorization server should validate the client id
              associated with the particular refresh token with every refresh
              request (<xref target="binding_refresh_client_id"></xref>).</t>

              <t>Limit token scope (<xref target="limit_scope"></xref>).</t>

              <t>Revoke refresh tokens
              (<xref target="refresh_revocation"></xref>).</t>

              <t>Revoke client secrets
              (<xref target="client_secret_revocation"></xref>).</t>

              <t>Refresh tokens can automatically be replaced in order to
              detect unauthorized token usage by another party (see "Refresh
              Token Rotation", <xref target="refresh_replace"></xref>).</t>
            </list></t>
          -->

          <t>
            <vspace blankLines="1" />
            攻撃例: Webアプリケーションからリフレッシュトークンを取得
          </t>
          <!--
          <t><vspace blankLines="1" />Attack: Obtain Refresh Token from Web
          Application:</t>
          -->

          <t>
            攻撃者はWebアプリケーションの脆弱性を突いてリフレッシュトークンを取得する可能性がある.
          </t>
          <!--
          <t>An attacker may obtain the refresh tokens issued to a web
          application by way of overcoming the web server's security controls.
          </t>
          -->

          <t>
            影響: Webアプリケーションでは複数ユーザーのアカウントが一括管理されているため, こういった攻撃によってそのサイト上のすべてのリフレッシュトークンが漏洩する可能性がある.
          </t>
          <!--
          <t>
          Impact: Since a web application manages the user accounts of a
          certain site, such an attack would result in an exposure of all
          refresh tokens on that site to the attacker.</t>
          -->

          <t>
            対抗策:
          </t>
          <!--
          <t>Countermeasures:</t>
          -->

          <t>
            <list style="symbols">
              <t>
                標準的なWebサーバーのセキュリティ対策を行う.
                (<xref target="std_web"></xref>)
              </t>
              <t>
                (クライアントアサーションやクライアントトークンなど) 強固なクライアント認証を行い, 攻撃者がトークンリフレッシュを行うために必要なクライアントシークレットの漏洩を防ぐ.
                (<xref target="strong_client_authn"></xref>)
              </t>
            </list>
          </t>
          <!--
          <t><list style="symbols">
              <t>Standard web server protection measures
              (<xref target="std_web"></xref>).</t>

              <t>Use strong client authentication
              (e.g., client_assertion/client_token) so the attacker cannot
              obtain the client secret required to exchange the tokens
              (<xref target="strong_client_authn"></xref>).</t>
            </list></t>
          -->

          <t>
            <vspace blankLines="1" />
            攻撃例: ネイティブアプリケーションからリフレッシュトークンを取得
          </t>
          <!--
          <t><vspace blankLines="1" />Attack: Obtain Refresh Token from Native
          Clients:</t>
          -->

          <t>
            ネイティブアプリケーションでは, リフレッシュトークンの漏洩は1ユーザーのみへの影響にとどまるケースがほとんどである.
          </t>
          <!--
          <t>On native clients, leakage of a refresh token typically affects a
          single user only.</t>
          -->

          <t>
            ローカルファイルシステムからの漏洩:
            攻撃者はデバイスのファイルシステムにアクセスし, リフレッシュトークンを取得する可能性がある.
            この攻撃のため, 攻撃者は不正なアプリケーションを経由することがある.
          </t>
          <!--
          <t>Read from local file system: The attacker could try to get file
          system access on the device and read the refresh tokens. The
          attacker could utilize a malicious application for that purpose.</t>
          -->

          <t>
            対抗策:
          </t>
          <!--
          <t>Countermeasures:</t>
          -->

          <t>
            <list style="symbols">
              <t>
                シークレットをセキュアストレージに保存する.
                (<xref target="secure_storage"></xref>)
              </t>
              <t>
                デバイスへの不正アクセスを防止するため, デバイスロック機能を利用する.
                (<xref target="device_lock"></xref>)
              </t>
            </list>
          </t>
          <!--
          <t><list style="symbols">
              <t>Store secrets in secure storage
              (<xref target="secure_storage"></xref>).</t>

              <t>Utilize device lock to prevent unauthorized device access
              (<xref target="device_lock"></xref>).</t>
            </list></t>
          -->

          <t>
            <vspace blankLines="1" />
            攻撃例: デバイス盗難
          </t>
          <!--
          <t><vspace blankLines="1" />Attack: Steal Device:</t>
          -->

          <t>
            ホストとなるデバイス (携帯電話など) が盗難される可能性もある.
            このケースでは, 攻撃者は被害ユーザーのすべてのアプリケーションにアクセスできる可能性がある.
          </t>
          <!--
          <t>The host device (e.g., mobile phone) may be stolen. In that case,
          the attacker gets access to all applications under the identity of
          the legitimate user.</t>
          -->

          <t>
            対抗策:
          </t>
          <!--
          <t>Countermeasures:</t>
          -->

          <t>
            <list style="symbols">
              <t>
                デバイスへの不正アクセスを防止するため, デバイスロック機能を利用する.
                (<xref format="default" target="device_lock"></xref>)
              </t>
              <t>
                ユーザーがデバイス盗難に気づいた時点で, 影響のあるトークンを無効化できるようにする.
                (<xref target="refresh_revocation"></xref>)
              </t>
            </list>
          </t>
          <!--
          <t><list style="symbols">
              <t>Utilize device lock to prevent unauthorized device access
              (<xref format="default" target="device_lock"></xref>).</t>

              <t>Where a user knows the device has been stolen, they can
              revoke the affected tokens
              (<xref target="refresh_revocation"></xref>).</t>
            </list></t>
          -->

          <t>
            <vspace blankLines="1" />
            攻撃例: デバイスコピー
          </t>
          <!--
          <t><vspace blankLines="1" />Attack: Clone Device:</t>
          -->

          <t>
            デバイス上の全データをその他のデバイスにコピーされる可能瀬がある.
            この場合, 後者のデバイスはあたかも前者のように振る舞う.
          </t>
          <!--
          <t>All device data and applications are copied to another device.
          Applications are used as-is on the target device.</t>
          -->

          <t>
            対抗策:
          </t>
          <!--
          <t>Countermeasures:</t>
          -->

          <t>
            <list style="symbols">
              <t>
                デバイスへの不正アクセスを防止するため, デバイスロック機能を利用する.
                (<xref format="default" target="device_lock"></xref>)
              </t>
              <t>
                トークンリフレッシュ時にデバイス自体の検証を行う.
                (<xref target="device_id"></xref>)
              </t>
              <t>
                Refresh Token Rotateを用いる.
                (<xref target="refresh_replace"></xref>)
              </t>
              <t>
                ユーザーがデバイスコピーに気づいた時点で, 影響のあるトークンを無効化できるようにする.
                (<xref target="refresh_revocation"></xref>)
              </t>
            </list>
          </t>
          <!--
          <t><list style="symbols">
              <t>Utilize device lock to prevent unauthorized device access
              (<xref format="default" target="device_lock"></xref>).</t>

              <t>Combine refresh token request with device identification
              (<xref target="device_id"></xref>).</t>

              <t>Refresh token rotation
              (<xref target="refresh_replace"></xref>).</t>

              <t>Where a user knows the device has been cloned, they
              can use refresh token revocation
              (<xref target="refresh_revocation"></xref>).</t>
            </list></t>
          -->
        </section>

        <section title="Threat: Obtaining Access Tokens">
          <t>
            クライアントタイプによっては, アクセストークンが攻撃者に漏洩するいくつかのパターンがある.
            アクセストークンが他のアプリケーションからアクセス可能ななんらかのストレージデバイスに保存されている場合には, アクセストークンが盗まれる可能性もある.
          </t>
          <!--
          <t>Depending on the client type, there are different ways that access
          tokens may be revealed to an attacker. Access tokens could be stolen
          from the device if the application stores them in a storage device
          that is accessible to other applications.</t>
          -->

          <t>
            影響: トークンがbearer tokenであり, クライアント識別に付加的なメカニズムが用いられていない場合, 攻撃者はそのトークンのscopeの範囲内でアクセスできるすべてのリソースにアクセス可能となる.
          </t>
          <!--
          <t>Impact: Where the token is a bearer token and no additional
          mechanism is used to identify the client, the attacker can access
          all resources associated with the token and its scope.</t>
          -->

          <t>
            対抗策:
          </t>
          <!--
          <t>Countermeasures:</t>
          -->

          <t>
            <list style="symbols">
              <t>
                アクセストークンを一時的なメモリー空間に保存し, アクセス制限を行う.
                (<xref target="access_tokens"></xref>)
              </t>
              <t>
                トークンのscopeを制限する.
                (<xref target="limit_scope"></xref>)
              </t>
              <t>
                アクセストークンをプライベートメモリー内にとどめるか, リフレッシュトークンと同様の保護策を取る.
                (<xref target="refresh_tokens"></xref>)
              </t>
              <t>
                アクセストークンの有効期間を短くする.
                (<xref target="short_exp_time"></xref>)
              </t>
            </list>
          </t>
          <!--
          <t><list style="symbols">
              <t>Keep access tokens in transient memory and limit grants
              (<xref target="access_tokens"></xref>).</t>

              <t>Limit token scope (<xref target="limit_scope"></xref>).</t>

              <t>Keep access tokens in private memory or apply same protection
              means as for refresh tokens
              (<xref target="refresh_tokens"></xref>).</t>

              <t>Keep access token lifetime short
              (<xref target="short_exp_time"></xref>).</t>
            </list></t>
          -->
        </section>

        <section title="Threat: End-User Credentials Phished Using Compromised or Embedded Browser">
          <t>
            不正なアプリケーションがエンドユーザーを騙し, 認可プロセスにおいてエンベッドブラウザを使ったフィッシング攻撃によりユーザーのパスワードを盗み取る可能性がある.
            またエンベッドブラウザの代わりに独自のユーザーインタフェースを用いる可能性も考えられる.
            このような方法では, TLSなどの視覚的な信頼メカニズムをバイパスすることができるのである.
            エンベッドもしくは内蔵クライアントインタフェースを用いる場合, クライアントアプリケーションが本来アクセス不可能であるはずの情報 (UID/password) へアクセスできる可能性がある.
          </t>
          <!--
          <t>A malicious application could attempt to phish end-user passwords
          by misusing an embedded browser in the end-user authorization
          process, or by presenting its own user interface instead of allowing
          a trusted system browser to render the authorization user interface.
          By doing so, the usual visual trust mechanisms may be bypassed (e.g.,
          Transport Layer Security (TLS) confirmation, web site mechanisms).
          By using an embedded or internal client application user
          interface, the client application has access to additional
          information to which it should not have access (e.g., UID/password).
          </t>
          -->

          <t>
            影響:
            クライアントアプリケーションもしくは通信自体が汚染されていると, ユーザーはそれに気がつかないであろう.
            またユーザーネームやパスワードなど, 認可処理の際にやりとりされるすべての情報を盗まれることとなる.
          </t>
          <!--
          <t>Impact: If the client application or the communication is
          compromised, the user would not be aware of this, and all
          information in the authorization exchange, such as username and
          password, could be captured.</t>
          -->

          <t>
            対応策:
          </t>
          <!--
          <t>Countermeasures:</t>
          -->

          <t>
            <list style="symbols">
              <t>
                OAuthフローはクライアントアプリケーションにパスワードが知られることなしに利用できるよう設計されている.
                クライアントはユーザーに直接クレデンシャルを尋ねるべきではない.
                加えて, OAuthは不正アプリケーションによる攻撃に対して保護策を施すものではなく, エンドユーザーのみがインストールするネイティブアプリケーションの信頼性についての責任を持っていることから, エンドユーザーにフィッシング攻撃や各種ベストプラクティスについて教育を施すことも重要であろう.
              </t>
            </list>
          </t>
          <!--
          <t><list style="symbols">
              <t>The OAuth flow is designed so that client applications never
              need to know user passwords. Client applications should avoid
              directly asking users for their credentials. In addition,
              end users could be educated about phishing attacks and best
              practices, such as only accessing trusted clients, as OAuth does
              not provide any protection against malicious applications and
              the end user is solely responsible for the trustworthiness of
              any native application installed.</t>

              <t>Client applications could be validated prior to publication
              in an application market for users to access. That validation is
              out of scope for OAuth but could include validating that the
              client application handles user authentication in an appropriate
              way.</t>

              <t>Client developers should not write client applications that
              collect authentication information directly from users and
              should instead delegate this task to a trusted system component,
              e.g., the system browser.</t>
            </list></t>
          -->
        </section>

        <section anchor="open_redirector_client"
                 title="Threat: Open Redirectors on Client">
          <t>
            オープンリダイレクタとは, 何の検証もなしにパラメーターとして指定された場所に対してユーザーエージェントをリダイレクトさせるエンドポイントのことである.
            認可サーバーがクライアントに部分的なリダイレクトURIの登録 (訳注: Hostのみ, Pathの一部のみなど) を許す場合, 攻撃者はクライアントが持つオープンリダイレクタを悪用し, 認可サーバーの検証をすり抜けて認可コードまたはアクセストークンを自身のコントロール下にあるエンドポイントに送信することが可能となる.
          </t>
          <!--
          <t>An open redirector is an endpoint using a parameter to
          automatically redirect a user agent to the location specified by the
          parameter value without any validation. If the authorization server
          allows the client to register only part of the redirect URI, an
          attacker can use an open redirector operated by the client to
          construct a redirect URI that will pass the authorization server
          validation but will send the authorization "code" or access token to
          an endpoint under the control of the attacker.</t>
          -->

          <t>
            影響: 攻撃者は認可コードやアクセストークンにアクセスすることが可能になる.
          </t>
          <!--
          <t>Impact: An attacker could gain access to authorization "codes" or
          access tokens.</t>
          -->

          <t>
            対抗策:
          </t>
          <!--
          <t>Countermeasures:</t>
          -->

          <t>
            <list style="symbols">
              <t>
                クライアントにリダイレクトURI全体を事前登録させる.
                (<xref target="val_redirect"></xref>)
              </t>
            </list>
          </t>
          <!--
          <t><list style="symbols">
              <t>Require clients to register full redirect URI
              (<xref target="val_redirect"></xref>).</t>
            </list></t>
          -->
        </section>
      </section>

      <section title="Authorization Endpoint">
        <t></t>

        <section title="Threat: Password Phishing by Counterfeit Authorization Server">
          <t>
            OAuthは認可サーバーの真正性検証は行わない.
            悪意ある者はこれを逆手に取って, クライアントのリクエストを遮り, 誤った, 場合によっては不正なレスポンスを返すことができる.
            この攻撃はDNSやAddress Resolution Protocol (ARP) のなりすまし (spoofing) によって実現できる.
            OAuthや類似プロトコルは, ユーザーに対してリダイレクトされた先でパスワードを入力するという行為に慣らすという側面も持つ.
            そのためユーザーが注意を怠ると, Webサイトの真正性を確認せずにクレデンシャルを入力してしまうことになり, 攻撃者にユーザーのパスワードを盗む機会を与えることとなる.
          </t>
          <!--
          <t>OAuth makes no attempt to verify the authenticity of the
          authorization server. A hostile party could take advantage of this
          by intercepting the client's requests and returning misleading or
          otherwise incorrect responses. This could be achieved using DNS or
          Address Resolution Protocol (ARP) spoofing. Wide deployment of
          OAuth and similar protocols may cause users to become inured to
          the practice of being redirected to web sites where they are
          asked to enter their passwords. If users are not careful to
          verify the authenticity of these web sites before entering
          their credentials, it will be possible for attackers to
          exploit this practice to steal users' passwords.</t>
          -->

          <t>
            対抗策:
          </t>
          <!--
          <t>Countermeasures:</t>
          -->

          <t>
            <list style="symbols">
              <t>
                認可サーバーはOAuth実装時にこのようなアタックを考慮し, 認可サーバーやレスポンスの真正性が問題となるすべてのリクエストにおいてTLSを必須とすべきである.
                (<xref target="server_authn"></xref>)
              </t>
              <t>
                認可サーバーはユーザーに対してフィッシング攻撃のリスクを教育し, ユーザーに認可サーバーの真正性を簡単に確認する手段を提供すべきである.
              </t>
            </list>
          </t>
          <!--
          <t><list style="symbols">
              <t>Authorization servers should consider such attacks when
              developing services based on OAuth and should require the use
              of transport-layer security for any requests where the
              authenticity of the authorization server or of request
              responses is an issue
              (see <xref target="server_authn"></xref>).</t>

              <t>Authorization servers should attempt to educate users about
              the risks posed by phishing attacks and should provide mechanisms
              that make it easy for users to confirm the authenticity of their
              sites.</t>
            </list></t>
          -->
        </section>

        <section title="Threat: User Unintentionally Grants Too Much Access Scope">
          <t>
            エンドユーザーの認可を受ける際, エンドユーザーは要求されたscopeおよび認可相手を理解していない場合もありうる.
            本来許可されるべきでないリソースへのアクセスを, 許可してしまうこともあるであろう.
          </t>
          <!--
          <t>When obtaining end-user authorization, the end user may not
          understand the scope of the access being granted and to whom, or they
          may end up providing a client with access to resources that should
          not be permitted.</t>
          -->

          <t>
            対抗策:
          </t>
          <!--
          <t>Countermeasures:</t>
          -->

          <t>
            <list style="symbols">
              <t>
                ユーザーに対して要求されたscope (リソースおよびパーミッション) についての分かりやすい説明を行う.
                (<xref target="informed_decisions"></xref>)
              </t>
              <t>
                クライアントごとに要求できるscopeを制限する.
                認可サーバーはクライアント識別子ごとにscopeを制御することを検討してもよい.
                なお, このような意思決定はクライアントと認可サーバーの間で行われるものであり, OAuthの定めるところではない.
                認可サーバーは, パブリッククライアントのscopeを狭めるなど, クライアントタイプごとに要求できるscopeを制限しても良い.
                (<xref target="limit_scope"></xref>)
              </t>
            </list>
          </t>
          <!--
          <t><list style="symbols">
              <t>Explain the scope (resources and the
              permissions) the user is about to grant in an understandable way
              (<xref target="informed_decisions"></xref>).</t>

              <t>Narrow the scope, based on the client. When obtaining end-user
              authorization and where the client requests scope, the
              authorization server may want to consider whether to honor that
              scope based on the client identifier. That decision is between
              the client and authorization server and is outside the scope of
              this spec. The authorization server may also want to consider
              what scope to grant based on the client type, e.g., providing
              lower scope to public clients
              (<xref target="limit_scope"></xref>).</t>
            </list></t>
          -->
        </section>

        <section anchor="mal_client3"
                 title="Threat: Malicious Client Obtains Existing Authorization by Fraud">
          <t>
            認可サーバーは既に同意済みのクライアントからの認可リクエストを自動承認することも考えられる.
            ユーザーが認可サーバーの認可エンドポイントにリダイレクトされた際, 認可サーバーはそのユーザーが既にそのクライアントに対してアクセスを許可していることを検知し, その場合はユーザーに同意画面を表示することなく自動的にクライアントに戻すことができる.
          </t>
          <!--
          <t>Authorization servers may wish to automatically process
          authorization requests from clients that have been previously
          authorized by the user. When the user is redirected to the
          authorization server's end-user authorization endpoint to grant
          access, the authorization server detects that the user has already
          granted access to that particular client. Instead of prompting the
          user for approval, the authorization server automatically redirects
          the user back to the client.</t>
          -->

          <t>
            不正なクライアントはこの機能を悪用し, 正規クライアントの代わりにここで得られる認可コードなどを取得する可能性がある.
          </t>
          <!--
          <t>A malicious client may exploit that feature and try to obtain
          such an authorization "code" instead of the legitimate client.</t>
          -->

          <t>
            対抗策:
          </t>
          <!--
          <t>Countermeasures:</t>
          -->

          <t>
            <list style="symbols">
              <t>
                認可サーバーは, クライアントが事前登録したリダイレクトURIが検証可能でない限り, パブリッククライアントに対して自動認可処理を行うべきではない.
                (<xref target="val_redirect"></xref>)
              </t>
              <t>
                認可サーバーは自動承認時に取得できるscopeを狭めることで, リスクを軽減できる.
                (<xref target="limit_scope"></xref>)
              </t>
            </list>
          </t>
          <!--
          <t><list style="symbols">
              <t>Authorization servers should not automatically process repeat
              authorizations to public clients unless the client is validated
              using a pre-registered redirect URI
              (<xref target="val_redirect"></xref>).</t>

              <t>Authorization servers can mitigate the risks associated with
              automatic processing by limiting the scope of access tokens
              obtained through automated approvals
              (<xref target="limit_scope"></xref>).</t>
            </list></t>
          -->
        </section>

        <section anchor="open_redirector" title="Threat: Open Redirector">
          <t>
            攻撃者は認可エンドポイントとリダイレクトURIパラメーターを使って, 認可サーバーをオープンリダイレクタとして利用することができる.
            オープンリダイレクタとは, 何の検証もなしにパラメーターとして指定された場所に対してユーザーエージェントをリダイレクトさせるエンドポイントのことである.
          </t>
          <!--
          <t>An attacker could use the end-user authorization endpoint and the
          redirect URI parameter to abuse the authorization server as an
          open redirector. An open redirector is an endpoint using a parameter
          to automatically redirect a user agent to the location specified by
          the parameter value without any validation.</t>
          -->

          <t>
            影響: 攻撃者はユーザーの認可サーバーに対する信頼を逆手に取り, フィッシング攻撃を仕掛けることができる.
          </t>
          <!--
          <t>Impact: An attacker could utilize a user's trust in an
          authorization server to launch a phishing attack.</t>
          -->

          <t>
            対抗策:
          </t>
          <!--
          <t>Countermeasures:</t>
          -->

          <t>
            <list style="symbols">
              <t>
                クライアントにリダイレクトURI全体を事前登録させる.
                (<xref target="val_redirect"></xref>)
              </t>
              <t>
                クライアント識別子やリダイレクトURIが検証されない限り, リダイレクトURIへのリダイレクトを行わない.
                (<xref target="val_redirect"></xref>)
              </t>
            </list>
          </t>
          <!--
          <t><list style="symbols">
              <t>Require clients to register any full redirect URIs
              (<xref target="val_redirect"></xref>).</t>

              <t>Don't redirect to a redirect URI if the client identifier
              or redirect URI can't be verified
              (<xref target="val_redirect"></xref>).</t>
            </list></t>
          -->
        </section>
      </section>

      <section title="Token Endpoint">
        <t></t>

        <section title="Threat: Eavesdropping Access Tokens">
          <t>
            攻撃者は認可サーバーとクライアントの通信を盗聴し, アクセストークンを取得する可能性がある.
          </t>
          <!--
          <t>Attackers may attempt to eavesdrop access tokens in transit from
          the authorization server to the client.</t>
          -->

          <t>
            影響: 攻撃者は該当アクセストークンの持つscopeの範囲内でアクセスできるすべてのリソースにアクセス可能になる.
          </t>
          <!--
          <t>Impact: The attacker is able to access all resources with the
          permissions covered by the scope of the particular access token.</t>
          -->

          <t>
            対抗策:
          </t>
          <!--
          <t>Countermeasures:</t>
          -->

          <t>
            <list style="symbols">
              <t>
                OAuth仕様に従って, 認可サーバーは通信がTLSで保護されていることを保証する必要がある.
                (<xref target="conf_requests"></xref>)
              </t>
              <t>
                end-to-endの秘匿性が保たれない場合, アクセストークンのscopeを狭めたり有効期限を短くしたりすることで, 漏洩時のリスクを軽減できる.
                (<xref target="limit_scope"></xref>, <xref target="short_exp_time"></xref>)
              </t>
            </list>
          </t>
          <!--
          <t><list style="symbols">
              <t>As per the core OAuth spec, the authorization servers must
              ensure that these transmissions are protected using
              transport-layer mechanisms such as TLS
              (see <xref target="conf_requests"></xref>).</t>

              <t>If end-to-end confidentiality cannot be guaranteed, reducing
              scope (see <xref target="limit_scope"></xref>) and expiry time
              (<xref target="short_exp_time"></xref>) for access tokens can be
              used to reduce the damage in case of leaks.</t>
            </list></t>
          -->
        </section>

        <section title="Threat: Obtaining Access Tokens from Authorization Server Database">
          <t>
            認可サーバーがhandleベースのアクセストークンを用いてそれをデータベースに保存している場合, この攻撃が可能になる.
            攻撃者はSQLインジェクションによって認可サーバーのデータベースアクセスを取得する可能性がある.
          </t>
          <!--
          <t>This threat is applicable if the authorization server stores
          access tokens as handles in a database. An attacker may obtain
          access tokens from the authorization server's database by gaining
          access to the database or launching a SQL injection attack.
          </t>
          -->

          <t>
            影響: 全アクセストークンの漏洩
          </t>
          <!--
          <t>Impact: Disclosure of all access tokens.</t>
          -->

          <t>
            対抗策:
          </t>
          <!--
          <t>Countermeasures:</t>
          -->

          <t>
            <list style="symbols">
              <t>
                システムレベルのセキュリティ対策を行う.
                (<xref target="std_sys"></xref>)
              </t>
              <t>
                アクセストークンのhash値のみを保存する.
                (<xref target="noclear"></xref>)
              </t>
              <t>
                標準的SQLインジェクション対策を行う.
                (<xref target="std_sql"></xref>)
              </t>
            </list>
          </t>
          <!--
          <t><list style="symbols">
              <t>Enforce system security measures
              (<xref target="std_sys"></xref>).</t>

              <t>Store access token hashes only
              (<xref target="noclear"></xref>).</t>

              <t>Enforce standard SQL injection countermeasures
              (<xref target="std_sql"></xref>).</t>
            </list></t>
          -->
        </section>

        <section title="Threat: Disclosure of Client Credentials during Transmission">
          <t>
            攻撃者は, クライアント認証時やOAuthトークンリクエスト時に, クライアント・サーバー間を送信されるクライアントクレデンシャルを盗聴することができる.
          </t>
          <!--
          <t>An attacker could attempt to eavesdrop the transmission of client
          credentials between the client and server during the client
          authentication process or during OAuth token requests.</t>
          -->

          <t>
            影響: クライアントクレデンシャルの漏洩は, クライアントサービスのフィッシングやなりすまし (impersonation) を容易にする.
          </t>
          <!--
          <t>Impact: Revelation of a client credential enabling phishing or
          impersonation of a client service.</t>
          -->

          <t>
            対抗策:
          </t>
          <!--
          <t>Countermeasures:</t>
          -->

          <t>
            <list style="symbols">
              <t>
                クライアントクレデンシャル送信時はTLSを用いる.
                (<xref target="conf_requests"></xref>)
              </t>
              <t>
                クレデンシャルを平文で送信する必要の無い認証方式を採用する.
                (HMACなど)
              </t>
            </list>
          </t>
          <!--
          <t><list style="symbols">
              <t>The transmission of client credentials must be protected
              using transport-layer mechanisms such as TLS
              (see <xref target="conf_requests"></xref>).</t>

              <t>Use alternative authentication means that do not require the
              sending of plaintext credentials over the wire (e.g., Hash-based
              Message Authentication Code).</t>
            </list></t>
          -->
        </section>

        <section title="Threat: Obtaining Client Secret from Authorization Server Database">
          <t>
            攻撃者は, SQLインジェクション攻撃によって, 正規のclient_id/secretペアを認可サーバーのデータベースから盗み出すことができる.
          </t>
          <!--
          <t>An attacker may obtain valid "client_id"/secret combinations from
          the authorization server's database by gaining access to the
          database or launching a SQL injection attack. </t>
          -->

          <t>
            影響: 全client_id/secretペアの漏洩. これは攻撃者にいかなる正規クライアントとしても動作することを許可する.
          </t>
          <!--
          <t>Impact: Disclosure of
          all "client_id"/secret combinations. This allows the attacker to act
          on behalf of legitimate clients.</t>
          -->

          <t>
            対抗策:
          </t>
          <!--
          <t>Countermeasures:</t>
          -->

          <t>
            <list style="symbols">
              <t>
                システムレベルのセキュリティ対策を行う.
                (<xref target="std_sys"></xref>)
              </t>
              <t>
                標準的SQLインジェクション対策を行う.
                (<xref target="std_sql"></xref>)
              </t>
              <t>
                "Enforce Credential Storage Protection Best Practices" に従って適切にクレデンシャルを扱う.
                (<xref target="cred_storage_prot"></xref>)
              </t>
            </list>
          </t>
          <!--
          <t><list style="symbols">
              <t>Enforce system security measures
              (<xref target="std_sys"></xref>).</t>

              <t>Enforce standard SQL injection countermeasures
              (<xref target="std_sql"></xref>).</t>

              <t>Ensure proper handling of credentials as per
              "Enforce Credential Storage Protection Best Practices"
              (<xref target="cred_storage_prot"></xref>).</t>
            </list></t>
          -->
        </section>

        <section title="Threat: Obtaining Client Secret by Online Guessing">
          <t>
            攻撃者は正規のclient_id/secretペアを推測できる.
          </t>
          <!--
          <t>An attacker may try to guess valid "client_id"/secret pairs.</t>
          -->

          <t>
            影響: 単一client_id/secretペアの漏洩.
          </t>
          <!--
          <t>Impact: Disclosure of a single "client_id"/secret pair.</t>
          -->

          <t>
            対抗策:
          </t>
          <!--
          <t>Countermeasures:</t>
          -->

          <t>
            <list style="symbols">
              <t>
                高エントロピーなシークレットを利用する.
                (<xref target="high_entropy"></xref>)
              </t>
              <t>
                アカウントをロックする.
                (<xref target="lock_accounts"></xref>)
              </t>
              <t>
                強固なクライアント認証を行う.
                (<xref target="strong_client_authn"></xref>)
              </t>
            </list>
          </t>
          <!--
          <t><list style="symbols">
              <t>Use high entropy for secrets
              (<xref target="high_entropy"></xref>).</t>

              <t>Lock accounts (<xref target="lock_accounts"></xref>).</t>

              <t>Use strong client authentication
              (<xref target="strong_client_authn"></xref>).</t>
            </list></t>
          -->
        </section>
      </section>

      <section title="Obtaining Authorization">
        <t>
          本セクションでは, アクセストークン取得時の各フローにおいて発生する脅威について述べる.
          それぞれのフローは, 認可エンドポイントおよびトークンエンドポイントにおけるレスポンスタイプとグラントタイプによって分類される.
        </t>
        <!--
        <t>This section covers threats that are specific to certain flows
        utilized to obtain access tokens. Each flow is characterized by
        response types and/or grant types on the end-user authorization and
        token endpoint, respectively.</t>
        -->

        <section anchor="code_flow" title="Authorization &quot;code&quot;">
          <section anchor="eavesdropping"
                   title="Threat: Eavesdropping or Leaking Authorization &quot;codes&quot;">
            <t>
              攻撃者により, 認可サーバーとクライアントの間の通信を盗聴され, 認可コードが漏洩する可能性がある.
              加えて認可コードはブラウザ経由で送信されるので, その他の方法で意図せず信頼できないサイトや攻撃者に漏洩する可能性がある.
            </t>
            <!--
            <t>An attacker could try to eavesdrop transmission of the
            authorization "code" between the authorization server and client.
            Furthermore, authorization "codes" are passed via the browser, which
            may unintentionally leak those codes to untrusted web sites and
            attackers in different ways:</t>
            -->

            <t>
              <list style="symbols">
                <t>
                  リファラヘッダー: ブラウザにより, Webページ内にembedされたコンテンツのロード時やページ遷移時に, "referer" ヘッダーが付与される.
                  これはヘッダー送信の対象サイトが元のサイトと信頼関係にない場合でも送信されうる.
                  リファラーヘッダーはトラフィック解析のためログに残されることが多い.
                </t>

                <t>
                  リクエストログ: Webサーバー上のリクエストログには, 一般的にリクエスト中のクエリーパラメータが含まれる.
                </t>

                <t>
                  オープンリダイレクタ: Webサイトはしばしばリダイレクタを通じてユーザーを別のサイトに遷移させる.
                  オープンリダイレクタは検証コード (訳注: 認可コードのことを指すと思われる) の漏洩の原因となりうる.
                </t>

                <t>
                  ブラウザ履歴: Webブラウザは一般的に訪問履歴を記録する.
                  同じブラウザを利用する場合, 過去に他のユーザーが訪問したURLが他者に漏洩する可能性がある.
                </t>
              </list>
              注: SAMLプロトコル仕様 <xref target="OASIS.sstc-saml-bindings-1.1"></xref> Section 4.1.1.9.1 および <xref target="OASIS.sstc-sec-analysis-response-01"></xref> にこれらと同様の攻撃に関する記述がある.
            </t>
            <!--
            <t><list style="symbols">
                <t>Referrer headers: Browsers frequently pass a
                &ldquo;referer&rdquo; header when a web page embeds content,
                or when a user travels from one web page to another web page.
                These referrer headers may be sent even when the origin site
                does not trust the destination site. The referrer header is
                commonly logged for traffic analysis purposes.</t>

                <t>Request logs: Web server request logs commonly include
                query parameters on requests.</t>

                <t>Open redirectors: Web sites sometimes need to send users to
                another destination via a redirector. Open redirectors pose a
                particular risk to web-based delegation protocols because the
                redirector can leak verification codes to untrusted
                destination sites.</t>

                <t>Browser history: Web browsers commonly record visited URLs
                in the browser history. Another user of the same web browser
                may be able to view URLs that were visited by previous
                users.</t>
              </list>Note: A description of similar attacks on the SAML
            protocol can be found at <xref
            target="OASIS.sstc-saml-bindings-1.1"></xref>, Section 4.1.1.9.1;
            <xref target="Sec-Analysis"></xref>; and <xref
            target="OASIS.sstc-sec-analysis-response-01"></xref>.</t>
            -->

            <t>
              対抗策:
            </t>
            <!--
            <t>Countermeasures:</t>
            -->

            <t>
              <list style="symbols">
                <t>
                  OAuth Core仕様にあるように, 認可サーバーおよびクライアントは, 通信がTLSなどのトランスポートレイヤーメカニズムによって保護されていることを保証しなければならない.
                  (<xref target="conf_requests"></xref>)
                </t>

                <t>
                  認可サーバーがクライアントに可能な限りクライアント認証を要求することで, 認可コードと対象クライアントとの紐付けを検証することができる.
                  (<xref target="bind_code_client_id"></xref>)
                </t>

                <t>
                  認可コードの有効期間を短くする. (<xref target="short_exp_time"></xref>)
                </t>

                <t>
                  認可サーバーは認可コードをOne-timeトークンとして扱う. (<xref target="one_time_usage"></xref>)
                </t>

                <t>
                  認可サーバーが認可コードが複数回使われたことを検知した場合, その認可コードを用いて発行されたすべてのトークンを無効化することも検討できる.
                  (<xref target="automatic_code_revocation"></xref>)
                </t>

                <t>
                  以上のような対抗策が実施できない場合は, アクセストークンのscopeを狭め, 有効期間を短くすることで, リスクを軽減できる.
                  (<xref target="limit_scope"></xref>, <xref target="short_exp_time"></xref>)
                </t>

                <t>
                  クライアントサイトはリダイレクトURIに対するブラウザキャッシュをクリアするため, ページをリロードすることを検討してもよい.
                </t>
              </list>
            </t>
            <!--
            <t><list style="symbols">
                <t>As per the core OAuth spec, the authorization server as
                well as the client must ensure that these transmissions are
                protected using transport-layer mechanisms such as TLS
                (see <xref target="conf_requests"></xref>).</t>

                <t>The authorization server will require the client to
                authenticate wherever possible, so the binding of the
                authorization "code" to a certain client can be validated in a
                reliable way
                (see <xref target="bind_code_client_id"></xref>).</t>

                <t>Use short expiry time for authorization "codes"
                (<xref target="short_exp_time"></xref>).</t>

                <t>The authorization server should enforce a one-time usage
                restriction (see  (<xref target="one_time_usage"></xref>)).</t>

                <t>If an authorization server observes multiple attempts to
                redeem an authorization "code", the authorization server may
                want to revoke all tokens granted based on the
                authorization "code"
                (see <xref target="automatic_code_revocation"></xref>).</t>

                <t>In the absence of these countermeasures, reducing scope
                (<xref target="limit_scope"></xref>) and expiry time (<xref
                target="short_exp_time"></xref>) for access tokens can be used
                to reduce the damage in case of leaks.</t>

                <t>The client server may reload the target page of the
                redirect URI in order to automatically clean up the browser
                cache.</t>
              </list></t>
            -->
          </section>

          <section title="Threat: Obtaining Authorization &quot;codes&quot; from Authorization Server Database">
            <t>
              認可サーバーがhandleとして認可コードをデータベースに保存した場合, この脅威が発生しうる.
              攻撃者は, データベースへのアクセス権限を不正取得したり, SQLインジェクション攻撃を通じて, 認可サーバーのデータベース中から認可コードを取得できる可能性がある.
            </t>
            <!--
            <t>This threat is applicable if the authorization server stores
            authorization "codes" as handles in a database. An attacker may
            obtain authorization "codes" from the authorization server's
            database by gaining access to the database or launching a SQL
            injection attack. </t>
            -->

            <t>
              影響: 全認可コードが漏洩し, おそらくさらにそれに紐づくredirect_uriとclient_idも漏洩する.
            </t>
            <!--
            <t>Impact: Disclosure of all authorization "codes",
            most likely along with the respective "redirect_uri" and "client_id"
            values.</t>
            -->

            <t>
              対抗策:
            </t>
            <!--
            <t>Countermeasures:</t>
            -->

            <t>
              <list style="symbols">
                <t>
                  クレデンシャルストレージを保護するためのベストプラクティスに従う.
                  (<xref target="cred_storage_prot"></xref>)
                </t>
                <t>
                  システムレベルのセキュリティ対策を行う.
                  (<xref target="std_sys"></xref>)
                </t>
                <t>
                  アクセストークンのハッシュ値のみを保存する.
                  (<xref target="noclear"></xref>)
                </t>
                <t>
                  標準的SQLインジェクション対策を行う.
                  (<xref target="std_sql"></xref>)
                </t>
              </list>
            </t>
            <!--
            <t><list style="symbols">
                <t>Best practices for credential storage protection should be
                employed (<xref target="cred_storage_prot"></xref>).</t>

                <t>Enforce system security measures
                (<xref target="std_sys"></xref>).</t>

                <t>Store access token hashes only
                (<xref target="noclear"></xref>).</t>

                <t>Enforce standard SQL injection countermeasures
                (<xref target="std_sql"></xref>).</t>
              </list></t>
            -->
          </section>

          <section title="Threat: Online Guessing of Authorization &quot;code&quot;s">
            <t>
              攻撃者が正規の認可コード値を推測し, 推測値を "code" グラントとして用いてアクセストークンを取得する可能性がある.
            </t>
            <!--
            <t>An attacker may try to guess valid authorization "code" values
            and send the guessed code value using the grant type
            &bdquo;code&ldquo; in order to obtain a valid access token.</t>
            -->

            <t>
              影響: 単一のアクセストークン, およびおそらくはそれと紐づいたリフレッシュトークンの漏洩・不正取得.
            </t>
            <!--
            <t>Impact: Disclosure of a single access token and probably also
            an associated refresh token.</t>
            -->

            <t>
              対抗策:
            </t>
            <!--
            <t>Countermeasures:</t>
            -->

            <t>
              <list style="symbols">
                <t>
                  handleベーストークンは高エントロピーでなければならない.
                  (<xref target="high_entropy"></xref>)
                </t>
                <t>
                  assertionベーストークンは署名されるべきである.
                  (<xref target="signed_tokens"></xref>)
                </t>
                <t>
                  クライアント認証を行う.
                  これにより攻撃者が推測しなければならない値が増える.
                  (<xref target="depl_specific_secretes"></xref>)
                </t>
                <t>
                  認可コードをリダイレクトURIと紐づける.
                  これにより攻撃者が推測しなければならない値が増える.
                  (<xref target="bind_code_redirect"></xref>)
                </t>
                <t>
                  トークンの有効期間を短くする.
                  (<xref target="short_exp_time"></xref>)
                </t>
              </list>
            </t>
            <!--
            <t><list style="symbols">
                <t>Handle-based tokens must use high entropy
                (<xref target="high_entropy"></xref>).</t>

                <t>Assertion-based tokens should be signed
                (<xref target="signed_tokens"></xref>).</t>

                <t>Authenticate the client; this adds another value that
                the attacker has to guess
                (<xref target="depl_specific_secretes"></xref>).</t>

                <t>Bind the authorization "code" to the redirect URI;
                this adds another value that the attacker has to guess
                (<xref target="bind_code_redirect"></xref>).</t>

                <t>Use short expiry time for tokens
                (<xref target="short_exp_time"></xref>).</t>
              </list></t>
            -->
          </section>

          <section anchor="mal_client"
                   title="Threat: Malicious Client Obtains Authorization">
            <t>
              不正クライアントが正規クライアントになりすましてアクセス認可を取得する可能性がある.
              不正クライアントによってはスクレイピングなどによりユーザーの同意フローをシミュレートすることも考えられる.
            </t>
            <!--
            <t>A malicious client could pretend to be a valid client and
            obtain an access authorization in this way. The malicious client
            could even utilize screen-scraping techniques in order to simulate
            a user's consent in the authorization flow.</t>
            -->

            <t>
              推測: ユーザーのデバイスを不正なソフトウェアから保護する責務は認可サーバーにはない.
              これは該当デバイス上で動作するプラットフォームの責務であり, プラットフォームはおそらく協調動作する (アプリケーションマネージメントインフラなどの) エコシステムと共同で, その任にあたるであろう.
              認可サーバーが単体として責任を持つのは, リソースサーバー上のエンドユーザーのリソースに対するアクセス制御, およびOAuthプロトコルを通じたそれらへの不正アクセスの防止である.
              この前提に基づき, ここで扱う脅威に対する対抗策として, 以下が考えられる.
            </t>
            <!--
            <t>Assumption: It is not the task of the authorization server to
            protect the end-user's device from malicious software. This is the
            responsibility of the platform running on the particular device,
            probably in cooperation with other components of the respective
            ecosystem (e.g., an application management infrastructure). The
            sole responsibility of the authorization server is to control
            access to the end-user's resources maintained in resource servers
            and to prevent unauthorized access to them via the OAuth protocol.
            Based on this assumption, the following countermeasures are
            available to cope with the threat.</t>
            -->

            <t>
              対抗策:
            </t>
            <!--
            <t>Countermeasures:</t>
            -->

            <t>
              <list style="symbols">
                <t>
                  認可サーバーは可能な限りクライアント認証を行うべきである. (<xref target="depl_specific_secretes"></xref>)
                  注: クライアント認証はエンドユーザーの認可プロセスの後に実施される.
                </t>

                <t>
                  認可サーバーは, 事前登録されたリダイレクトURIがあれば, それを用いてクライアントが指定したリダイレクトURIを検証するべきである.
                  (<xref target="val_redirect"></xref>)
                  注: 不正なリダイレクトURIは不正クライアントによるアクセスを予測させるが, 正しいリダイレクトURIが正規のクライアントによるアクセスを保証する分けではないことに注意すること.
                  リダイレクトURIの信頼性は, クライアントタイプに依存する.
                  Webアプリケーションの場合, そのリダイレクトURIはグローバルにユニークかつFQDNがHTTPSサーバー認証を通じて検証されるため高い信頼を置ける.
                  一方ネイティブクライアントでは, リダイレクトURIは多くの場合デバイスローカルなリソース (カスタムスキーマなど) を指す.
                  よって, あるデバイス上では不正クライアントが正規クライアントのリダイレクトURIを利用可能であるような状況も考えられる.
                </t>

                <t>
                  エンドユーザーを認証した後, 認可サーバーは該当ユーザーに同意を求めるべきである.
                  ここで認可サーバーはクライアントによるアクセスの目的, scope, および認可の有効期間をエンドユーザーに示すべきである.
                  さらに, 認可サーバーはユーザーにクライアントの身元を示すいかなる情報をも提示すべきである.
                  ここで示される情報を使った特定アプリケーションの検証, および認可リクエストの許可/拒否の決定については, ユーザーに委ねられる.
                  (<xref target="validation_end_user"></xref>)
                </t>

                <t>
                  認可サーバーは, 信頼できる方法によって認証もしくは検証されたクライアント以外に対しては, 自動再承認処理を行うべきではない.
                  (<xref target="automatic_processing"></xref>)
                </t>

                <t>
                  認可サーバーがエンドユーザーの自動認証を行う場合, スクレイピングを防ぐ手段がなくなる可能性がある.
                  こういった手段としては, CAPTCHAsや各種マルチファクター認証技術などが挙げられる.
                </t>

                <t>
                  認可サーバーは, 信頼できる方法によって認証できないクライアントに対しては, 発行するトークンのスコープを制限することもありうる.
                  (<xref target="limit_scope"></xref>)
                </t>
              </list>
            </t>

            <!--
            <t><list style="symbols">
                <t>The authorization server should authenticate the client, if
                possible (see <xref target="depl_specific_secretes"></xref>).
                Note: The authentication takes place after the end user has
                authorized the access.</t>

                <t>The authorization server should validate the client's
                redirect URI against the pre-registered redirect URI, if
                one exists (see <xref target="val_redirect"></xref>). Note: An
                invalid redirect URI indicates an invalid client, whereas a
                valid redirect URI does not necessarily indicate a valid
                client. The level of confidence depends on the client type.
                For web applications, the level of confidence is high, since
                the redirect URI refers to the globally unique network endpoint
                of this application, whose fully qualified domain name (FQDN)
                is also validated using HTTPS server authentication by the
                user agent. In contrast, for native clients, the redirect URI
                typically refers to device local resources, e.g., a custom
                scheme. So, a malicious client on a particular device can use
                the valid redirect URI the legitimate client uses on all other
                devices.</t>

                <t>After authenticating the end user, the authorization server
                should ask him/her for consent. In this context, the
                authorization server should explain to the end user the
                purpose, scope, and duration of the authorization the client
                asked for. Moreover, the authorization server should show the
                user any identity information it has for that client. It is up
                to the user to validate the binding of this data to the
                particular application (e.g., Name) and to approve the
                authorization request
                (see <xref target="validation_end_user"></xref>).</t>

                <t>The authorization server should not perform automatic
                re&nbhy;authorizations for clients it is unable to reliably
                authenticate or validate
                (see <xref target="automatic_processing"></xref>).</t>

                <t>If the authorization server automatically authenticates the
                end user, it may nevertheless require some user input in order
                to prevent screen scraping. Examples are CAPTCHAs (Completely
                Automated Public Turing tests to tell Computers and Humans
                Apart) or other multi-factor authentication techniques such as
                random questions, token code generators, etc.</t>

                <t>The authorization server may also limit the scope of tokens
                it issues to clients it cannot reliably authenticate
                (see <xref target="limit_scope"></xref>).</t>
              </list></t>
            -->
          </section>

          <section title="Threat: Authorization &quot;code&quot; Phishing">
            <t>
              悪意あるアプリケーションがクライアントサイトになりすまし, 認可コードを取得する可能性がある.
              DNSやARPのなりすましがその要因となる.
              このような脅威は, Webアプリケーション型のクライアントにあてはまる.
              そのようなクライアントのリダイレクトURIは, ユーザのブラウザが動作するローカルホストではない別の場所を指すためである.
            </t>
            <!--
            <t>A hostile party could impersonate the client site and get
            access to the authorization "code". This could be achieved using DNS
            or ARP spoofing. This applies to clients, which are web
            applications; thus, the redirect URI is not local to the host where
            the user's browser is running.</t>
            -->

            <t>
              影響: この脅威はWebアプリケーションにあてはまり, 認可コード, そして潜在的にはそれに紐づくアクセストークンおよびリフレッシュトークンの漏洩につながる.
            </t>
            <!--
            <t>Impact: This affects web applications and may lead to a
            disclosure of authorization "codes" and, potentially, the
            corresponding access and refresh tokens.</t>
            -->

            <t>
              対抗策:
            </t>
            <!--
            <t>Countermeasures:</t>
            -->

            <t>
              このような攻撃を防ぐため, 以下のいずれかの対策を講じることを強く推奨する.
            </t>
            <!--
            <t>It is strongly recommended that one of the following
            countermeasures be utilized in order to prevent this attack:</t>
            -->

            <t>
              <list style="symbols">
                <t>
                  クライアントのリダイレクトURIは, HTTPSで保護されたエンドポイントを指すべきである.
                  またブラウザのサーバー認証機能を用いて, 確実にそのリダイレクトURIを認証すべきである.
                  (<xref target="server_authn"></xref>)
                </t>

                <t>
                  認可サーバーはクライアント認証を要求するべきである.
                  それにより認可コードと特定のクライアントとの紐付けが, 信頼できる方法で検証可能となる.
                  (<xref target="bind_code_client_id"></xref>)
                </t>
              </list>
            </t>
            <!--
            <t><list style="symbols">
                <t>The redirect URI of the client should point to an HTTPS-protected endpoint, and the browser should be utilized to
                authenticate this redirect URI using server authentication
                (see <xref target="server_authn"></xref>).</t>

                <t>The authorization server should require that the client be
                authenticated, i.e., confidential client, so the binding of the
                authorization "code" to a certain client can be validated in a
                reliable way
                (see <xref target="bind_code_client_id"></xref>).</t>
              </list></t>
            -->
          </section>

          <section title="Threat: User Session Impersonation">
            <t>
              悪意あるアプリケーションがクライアントサイトになりすまし, クライアント上のユーザーセッションを偽装する可能性がある.
              DNSやARPのなりすましがその要因となる.
              このような脅威は, Webアプリケーション型のクライアントにあてはまる.
              そのようなクライアントのリダイレクトURIは, ユーザのブラウザが動作するローカルホストではない別の場所を指すためである.
            </t>
            <!--
            <t>A hostile party could impersonate the client site and
            impersonate the user's session on this client. This could be
            achieved using DNS or ARP spoofing. This applies to clients, which
            are web applications; thus, the redirect URI is not local to the
            host where the user's browser is running.</t>
            -->

            <t>
              影響: ブラウザ経由でコールバックエンドポイントに送信される認可コードが攻撃者に漏洩する.
              攻撃者は, そこでフローを中断し, 得られた認可コードを抜き出して自らクライアントに送ることで, 保護リソースへのアクセス権限を得る.
              クライアントは渡された認可コードをそのままアクセストークンと交換し, 得られたアクセストークンを使って保護リソースアクセスを行う.
              これによって攻撃者は被害者の管理下にある保護リソースを取得したり, それを書き換えたりすることで, なんらかの利益を得る.
              (サードパーティーSNS上のログインボタンなどのように) OAuthが認証処理の委譲の為に用いられている場合, 攻撃者は得られた認可コードを使って被害者としてクライアントにログインできる.
            </t>
            <!--
            <t>Impact: An attacker who intercepts the authorization "code" as it
            is sent by the browser to the callback endpoint can gain access to
            protected resources by submitting the authorization "code" to the
            client. The client will exchange the authorization "code" for an
            access token and use the access token to access protected
            resources for the benefit of the attacker, delivering protected
            resources to the attacker, or modifying protected resources as
            directed by the attacker. If OAuth is used by the client to
            delegate authentication to a social site (e.g., as in the
            implementation of a "Login" button on a third-party social network
            site), the attacker can use the intercepted authorization "code" to
            log into the client as the user.</t>
            -->

            <t>
              注: 認可コードをアクセストークンと交換する際のクライアント認証は, この攻撃を防ぐためには利用できない.
              このケースでは, トークンを取得するのはあくまで正規のクライアントである.
            </t>
            <!--
            <t>Note: Authenticating the client during authorization "code"
            exchange will not help to detect such an attack, as it is the
            legitimate client that obtains the tokens.</t>
            -->

            <t>
              対抗策:
            </t>
            <!--
            <t>Countermeasures:</t>
            -->

            <t>
              <list style="symbols">
                <t>
                  エンドユーザーセッションの偽装を防ぐには, クライアントのリダイレクトURIは, HTTPSで保護されたエンドポイントを指すべきである.
                  またブラウザのサーバー認証機能を用いて, 確実にそのリダイレクトURIを認証すべきである.
                  (<xref target="server_authn"></xref>)
                </t>
              </list>
            </t>
            <!--
            <t><list style="symbols">
                <t>In order to prevent an attacker from impersonating the
                end-user's session, the redirect URI of the client should
                point to an HTTPS protected endpoint, and the browser should be
                utilized to authenticate this redirect URI using server
                authentication (see <xref target="server_authn"></xref>).</t>
              </list></t>
            -->
          </section>

          <section anchor="authz_code_leakage"
                   title="Threat: Authorization &quot;code&quot; Leakage through Counterfeit Client">
            <t>
              この攻撃では, 攻撃者は認可コードグラントタイプを悪用し, 別のユーザー (被害者) に認可サーバーへのログインおよび被害者自身のリソースへのアクセス許可を行わせ, 得られた認可コードを攻撃者のアカウントを使ってクライアントに渡す.
              被害者によるリソースへのアクセス認可を, クライアントサイト上の攻撃者アカウントと紐づけることが, その目的である.
            </t>
            <!--
            <t>The attacker leverages the authorization "code" grant type in an
            attempt to get another user (victim) to log in, authorize access
            to his/her resources, and subsequently obtain the
            authorization "code" and inject it into a client application
            using the attacker's account. The goal is to associate an
            access authorization for resources of the victim with the
            user account of the attacker on a client site.</t>
            -->

            <t>
              攻撃者は既存クライアントを悪用し, それを自身の悪意あるサイトと組み合わせて利用する.
              これは被害者の「クライアントアプリケーションは特定のリソースサーバーへのアクセスを要求しているのだろう」という思い込みを利用した攻撃である.
              被害者は正規クライアントから発行された正常なリクエストを目にするため, そのリクエストを受理するであろう.
              そして攻撃者は被害者が知らず知らずのうちに認可してしまった情報へのアクセス権限を得るのである.
            </t>
            <!--
            <t>The attacker abuses an existing client application and combines
            it with his own counterfeit client web site. The attacker depends
            on the victim expecting the client application to request access to
            a certain resource server. The victim, seeing only a normal request
            from an expected application, approves the request. The attacker
            then uses the victim's authorization to gain access to the
            information unknowingly authorized by the victim.</t>
            -->

            <t>
              この攻撃は以下のフローで行われる.
            </t>
            <!--
            <t>The attacker conducts the following flow:</t>
            -->

            <t>
              <list style="numbers">
                <t>
                  攻撃者はクライアントサイト (もしくはクライアントアプリケーション) にアクセスし, 特定のリソースサーバーへのデータアクセスを行う.
                  クライアントWebサイトはそれを受けて, リソースサーバーに対応する認可サーバーへ, 認可リクエストを行う.
                  ここで攻撃者はこの認可プロセスを途中で止め, 認可サーバーの認可エンドポイントに自身のコントロール下にあるWebサイト上のリダイレクトURIを付与する.
                </t>

                <t>
                  攻撃者は改竄された認可エンドポイントURLを (emailやブログ記事中のリンクなどを経由して) 被害者に開かせる.
                  被害者に該当URLを開かせる手段については, ここでは特に限定しない.
                </t>

                <t>
                  リンクをクリックすることで, 被害者は認証を要求され, その後クライアントによるリソースアクセスへの同意を求められる.
                </t>

                <t>
                  認可プロセスが完了すると, 認可サーバーはユーザーエージェントを元のクライアントではなく攻撃者のWebサイトにリダイレクトさせる.
                </t>

                <t>
                  それにより攻撃者はなんらかの方法で該当認可コードを得る.
                  その具体的な手段についてはここでは触れない.
                </t>

                <t>
                  その後攻撃者は対象Webサイト (もしくはアプリケーション) の本来のリダイレクトURIに得られた認可コードを付与し, 自身のユーザーエージェントでそのURLをロードする.
                  これにより認可コードは元のクライアントサイト (もしくはアプリケーション) に渡される.
                </t>

                <t>
                  クライアントサイトは得られた認可コードをアクセストークンと交換し, それを自身のサイト上の攻撃者のアカウントと紐づける.
                </t>

                <t>
                  以上により, 攻撃者は該当クライアントサイトを通じて被害者のリソースへのアクセス権限を得る.
                </t>
              </list>
            </t>
            <!--
            <t><list style="numbers">
                <t>The attacker accesses the client web site (or application)
                and initiates data access to a particular resource server. The
                client web site in turn initiates an authorization request to
                the resource server's authorization server. Instead of
                proceeding with the authorization process, the attacker
                modifies the authorization server end-user authorization URL
                as constructed by the client to include a redirect URI
                parameter referring to a web site under his control
                (attacker's web site).</t>

                <t>The attacker tricks another user (the victim) into opening
                that modified end-user authorization URI and authorizing access
                (e.g., via an email link or blog link). The way the attacker
                achieves this goal is out of scope.</t>

                <t>Having clicked the link, the victim is requested to
                authenticate and authorize the client site to have access.</t>

                <t>After completion of the authorization process, the
                authorization server redirects the user agent to the
                attacker's web site instead of the original client web
                site.</t>

                <t>The attacker obtains the authorization "code" from his web
                site by means that are out of scope of this document.</t>

                <t>He then constructs a redirect URI to the target web site
                (or application) based on the original authorization request's
                redirect URI and the newly obtained authorization "code", and
                directs his user agent to this URL. The authorization "code" is
                injected into the original client site (or application).</t>

                <t>The client site uses the authorization "code" to fetch a
                token from the authorization server and associates this token
                with the attacker's user account on this site.</t>

                <t>The attacker may now access the victim's resources using
                the client site.</t>
              </list></t>
            -->

            <t>
              影響: 攻撃者はクライアントサイト上の自身のアカウントを通じて被害者のリソースへのアクセス権限を得る.
            </t>
            <!--
            <t>Impact: The attacker gains access to the victim's resources as
            associated with his account on the client site.</t>
            -->

            <t>
              対抗策:
            </t>
            <!--
            <t>Countermeasures:</t>
            -->

            <t>
              <list style="symbols">
                <t>
                  攻撃者は認可フローを途中でインターセプトするため, 外部サイトのリダイレクトURIを利用する必要がある.
                  よって認可サーバーが, 認可コードをその認可リクエスト時に指定されたリダイレクトURIと紐づけ, そのリダイレクトURIを用いてトークンエンドポイントで再び送られてくるリダイレクトURIを検証することで, この攻撃を検知することができる.
                  (<xref target="bind_code_redirect"></xref>)
                </t>

                <t>
                  さらに, 認可サーバーはリダイレクトURIの事前登録およびその検証を必須とすることもできる. (<xref target="val_redirect"></xref>)
                  これによりさらに早い段階で不正クライアントへの認可コード漏洩を検知することができる.
                </t>

                <t>
                  ネイティブアプリケーションの場合, 認可コードとクライアントIDの紐付けに加え, 各インスタンスごとに固有のクライアントID & シークレットを用いることもできる.
                  (<xref target="bind_code_client_id"></xref>, <xref target="depl_specific_secretes"></xref>)
                  攻撃者はインスタンス固有のシークレットへアクセスできないため, 攻撃者が認可コードをトークンと交換することは不可能になる.
                </t>

                <t>
                  クライアントは, この攻撃に対して脆弱なフローの代わりに, implicitグラントタイプやリソースオーナーパスワードグラントタイプなどの別フローを用いることもできる.
                  (<xref target="implicit_flow"></xref>, <xref target="pwd_flow"></xref>)
                  (訳注: implicitグラントタイプやリソースオーナーパスワードグラントタイプは, 別の攻撃に対して脆弱な一面があることに注意すること)
                </t>
              </list>
            </t>
            <!--
            <t><list style="symbols">
                <t>The attacker will need to use another redirect URI for
                its authorization process rather than the target web site
                because it needs to intercept the flow. So, if the
                authorization server associates the authorization "code" with
                the redirect URI of a particular end-user authorization and
                validates this redirect URI with the redirect URI passed
                to the token's endpoint, such an attack is detected
                (see <xref target="bind_code_redirect"></xref>).</t>

                <t>The authorization server may also enforce the usage and
                validation of pre-registered redirect URIs (see <xref
                target="val_redirect"></xref>). This will allow for early
                recognition of authorization "code" disclosure to counterfeit
                clients.</t>

                <t>For native applications, one could also consider using
                deployment-specific client ids and secrets (see <xref
                target="depl_specific_secretes"></xref>), along with the
                binding of authorization "codes" to "client_ids" (see <xref
                target="bind_code_client_id"></xref>) to detect such an
                attack because the attacker does not have access to the
                deployment-specific secret. Thus, he will not be able to
                exchange the authorization "code".</t>

                <t>The client may consider using other flows that are not
                vulnerable to this kind of attack, such as the implicit grant
                type (see <xref target="implicit_flow"></xref>) or
                resource owner password credentials (see <xref
                target="pwd_flow"></xref>).</t>
              </list></t>
            -->
          </section>

          <section anchor="section_csrf"
                   title="Threat: CSRF Attack against redirect-uri">
            <t>
              Cross-site request forgery (CSRF) は, Webサイトに信頼もしくは認証されたユーザーを通じてHTTPリクエストを実行させる, Webベースの攻撃である.
              攻撃にはHTTPリダイレクトやHTMLフォームなどが用いられる.
              OAuth認可フローに対するCSRF攻撃は, 攻撃者がOAuthの保護リソースへのアクセス権限を取得する際に, ユーザー同意ステップをスキップすることを可能にする.
            </t>
            <!--
            <t>Cross-site request forgery (CSRF) is a web-based attack whereby
            HTTP requests are transmitted from a user that the web site trusts
            or has authenticated (e.g., via HTTP redirects or HTML forms).
            CSRF attacks on OAuth approvals can allow an attacker to obtain
            authorization to OAuth protected resources without the consent of
            the user.</t>
            -->

            <t>
              この攻撃は認可コードフロー中でリダイレクトURIに対して行われる.
              攻撃者は, 自身の保護リソースに対する認可を行い, 認可コードを取得する.
              その後攻撃者は自身のデバイス上でクライアントへのリダイレクトを途中で止め, 被害者にそのリダイレクトリクエストを実行させる.
              リダイレクトを受けたクライアントは, 認可サーバーからトークンを取得し, クライアント上の被害者セッションとそのトークンでアクセスできるリソースを紐づける.
            </t>
            <!--
            <t>This attack works against the redirect URI used in the
            authorization "code" flow. An attacker could authorize an
            authorization "code" to their own protected resources on an
            authorization server. He then aborts the redirect flow back to the
            client on his device and tricks the victim into executing the
            redirect back to the client. The client receives the redirect,
            fetches the token(s) from the authorization server, and associates
            the victim's client session with the resources accessible using
            the token.</t>
            -->

            <t>
              影響: 被害者は攻撃者の代理としてリソースアクセスを行う.
              その栄養はアクセスされるリソースに依存するが, 例えば被害者が攻撃者のリソースとしてプライベートなデータをアップロードするケースなどが考えられる.
              OAuthを3rd partyログインの為に用いている場合, クライアント上の被害者アカウントが外部Identity Provider上の攻撃者アカウントと紐づけられてしまい, 攻撃者が別デバイス上で被害者としてクライアントにログインできるようになってしまう, といったケースも考えられる.
            </t>
            <!--
            <t>Impact: The user accesses resources on behalf of the attacker.
            The effective impact depends on the type of resource accessed. For
            example, the user may upload private items to an attacker's
            resources. Or, when using OAuth in 3rd-party login scenarios, the
            user may associate his client account with the attacker's identity
            at the external Identity Provider. In this way, the attacker could
            easily access the victim's data at the client by logging in from
            another device with his credentials at the external Identity
            Provider.</t>
            -->

            <t>
              対抗策:
            </t>
            <!--
            <t>Countermeasures:</t>
            -->

            <t>
              <list style="symbols">
                <t>
                  認可リクエストとそのリダイレクトレスポンスを紐づけるため, stateパラメーターを利用すべきである.
                  (<xref target="link_state_uasession"></xref>)
                </t>

                <t>
                  クライアント開発者とエンドユーザーに, 信頼できないURLにアクセスすべきでないと教育するといったことも考えられる.
                </t>
              </list>
            </t>
            <!--
            <t><list style="symbols">
                <t>The "state" parameter should be used to link the
                authorization request with the redirect URI used to deliver
                the access token
                (<xref target="link_state_uasession"></xref>).</t>

                <t>Client developers and end users can be educated to not
                follow untrusted URLs.</t>
              </list></t>
            -->
          </section>

          <section title="Threat: Clickjacking Attack against Authorization">
            <t>
              Clickjackingとは, 不正なサイトが不可視iframe (<xref target="iFrame"></xref>) に対象サイトをロードし, 対象サイト上の重要なボタンに会うようにその下のレイヤーに偽ボタンを配置し, 被害者のクリックを誘導する攻撃である.
              ユーザーが可視ボタンをクリックすると, 実際には不可視ページ上のボタンがクリックされる. (「認可」ボタンなど)
            </t>
            <!--
            <t>With clickjacking, a malicious site loads the target site in a
            transparent iFrame (see <xref target="iFrame"></xref>) overlaid on
            top of a set of dummy buttons that are carefully constructed to
            be placed directly under important buttons on the target site.
            When a user clicks a visible button, they are actually clicking a
            button (such as an "Authorize" button) on the hidden page.</t>
            -->

            <t>
              影響: 攻撃者はユーザーの認証クレデンシャル (訳注: ID & Passwordなど) やリソースアクセスを得る.
            </t>
            <!--
            <t>Impact: An attacker can steal a user's authentication
            credentials and access their resources.</t>
            -->

            <t>
              対抗策:
            </t>
            <!--
            <t>Countermeasures:</t>
            -->

            <t>
              <list style="symbols">
                <t>
                  モダンブラウザでは, X-FRAME-OPTIONSヘッダーを利用して認可フロー中でiframeの利用を禁止することができる.
                  (<xref target="clickjacking_xframe"></xref>)
                </t>

                <t>
                  レガシーブラウザでは, JavaScript frame-busting (<xref target="Framebusting"></xref>) が利用できる.
                  ただしこれはすべてのブラウザで動作するとは限らない.
                </t>
              </list>
            </t>
            <!--
            <t><list style="symbols">
                <t>For newer browsers, avoidance of iFrames during
                authorization can be enforced on the server side by using the
                X-FRAME-OPTIONS header
                (<xref target="clickjacking_xframe"></xref>).</t>

                <t>For older browsers, JavaScript frame-busting (see <xref
                target="Framebusting"></xref>) techniques can be used but may
                not be effective in all browsers.</t>
              </list></t>
            -->
          </section>

          <section title="Threat: Resource Owner Impersonation">
            <t>
              クライアントが保護リソースへのアクセスを要求する際, 通常認可フローではリソースオーナーの明示的なアクセス許可/拒否が行われる.
              しかしながら, 不正クライアントが認可フローの詳細を把握し, プログラムによって認可フローに必要なリクエストを実行することも考えられる.
              こうすることにより, クライアントはユーザー同意なしに被害者のリソースへのアクセス権限を得ることができる.
              認可サーバーがユーザーインタラクションを必要としない認証手法を取ったり, 複数ページにまたがる認可フローを分割可能にしていると, このような攻撃に対して脆弱になる.
            </t>
            <!--
            <t>When a client requests access to protected resources, the
            authorization flow normally involves the resource owner's explicit
            response to the access request, either granting or denying access
            to the protected resources. A malicious client can exploit
            knowledge of the structure of this flow in order to gain
            authorization without the resource owner's consent, by
            transmitting the necessary requests programmatically and
            simulating the flow against the authorization server. That way,
            the client may gain access to the victim's resources without her
            approval. An authorization server will be vulnerable to this
            threat if it uses non-interactive authentication mechanisms or
            splits the authorization flow across multiple pages.</t>
            -->

            <t>
              不正クライアントは不可視HTMLユーザーエージェントを利用して認可サーバーが送信するHTMLフォームを中断し, 自動的に同様のHTTP POSTリクエストを実行する.
              なお, このとき攻撃者は認可サーバー上でリソースオーナーの認証済セッションを利用できる必要がある.
              これは以下のような手段で実現可能となる.
            </t>
            <!--
            <t>The malicious client might embed a hidden HTML user agent,
            interpret the HTML forms sent by the authorization server, and
            automatically send the corresponding form HTTP POST requests. As a
            prerequisite, the attacker must be able to execute the
            authorization process in the context of an already-authenticated
            session of the resource owner with the authorization server. There
            are different ways to achieve this:</t>
            -->

            <t>
              <list style="symbols">
                <t>
                  不正クライアントは, 該当デバイス上の外部ブラウザやクロスブラウザクッキーに残っている既存セッションを悪用することができる.
                </t>

                <t>
                  不正クライアントは, まずユーザーに承認できる程度のscopeの認可を要求し, その後ブラウザに残されたセッションをこっそり悪用して他のscopeへのアクセスを得ることができる.
                </t>

                <t>
                  その他に, 攻撃者は認可サーバーのユーザーインタラクションを必要としないリソースオーナー認証メカニズムを悪用することもできる. (例: クライアント証明書など)
                </t>
              </list>
              いずれのケースでも, 攻撃は被害者のデバイス上のユーザーエージェント, もしくはネイティブアプリケーションで実行される必要がある.
            </t>
            <!--
            <t><list style="symbols">
                <t>The malicious client could abuse an existing session in an
                external browser or cross-browser cookies on the particular
                device.</t>

                <t>The malicious client could also request authorization for
                an initial scope acceptable to the user and then silently
                abuse the resulting session in his browser instance to
                "silently" request another scope.</t>

                <t>Alternatively, the attacker might exploit an authorization
                server's ability to authenticate the resource owner
                automatically and without user interactions, e.g., based on
                certificates.</t>
              </list> In all cases, such an attack is limited to clients
            running on the victim's device, either within the user agent or
            as a native app.</t>
            -->

            <t>
              注: この攻撃はCSRF対策では防止できない.
              攻撃者は認可サーバー自身で構築されたnonceなどを含むURLを「実行」しているに過ぎない.
              (訳注: Cookieなどもすべて取られているという仮定であろう)
            </t>
            <!--
            <t>Please note: Such attacks cannot be prevented using CSRF
            countermeasures, since the attacker just "executes" the URLs as
            prepared by the authorization server including any nonce, etc.</t>
            -->

            <t>
              対抗策:
            </t>
            <!--
            <t>Countermeasures:</t>
            -->

            <t>
              認可サーバーは自身のリスク分析に基づき, この脅威を検知および防止すべきかどうか決定すべきである.
            </t>
            <!--
            <t>Authorization servers should decide, based on an analysis of
            the risk associated with this threat, whether to detect and
            prevent this threat.</t>
            -->

            <t>
              この攻撃を防ぐため, 認可サーバーは以下のように推測不可能な入力値を伴うユーザーインタラクションを強制することも考えられる.
            </t>
            <!--
            <t>In order to prevent such an attack, the authorization server
            may force a user interaction based on non-predictable input values
            as part of the user consent approval. The authorization server
            could</t>
            -->

            <t>
              <list style="symbols">
                <t>
                  パスワード認証とユーザー同意を単一のフォームにする.
                </t>

                <t>
                  CAPTCHAを用いる.
                </t>

                <t>
                  なんらかの手段でリソースオーナーにOne-timeシークレットを送信し, それを利用させる.
                  (テキストメッセージ, インスタントメッセージなどを利用)
                </t>
              </list>
              その他に, リソースオーナーに不正アクセスを検知させるため, 認可サーバーがアクセス認可が行われた際にリソースオーナーに適切な手段で通知するという方法も考えられる.
              (テキストメッセージ, インスタントメッセージ, emailなどを利用)
            </t>
            <!--
            <t><list style="symbols">
                <t>combine password authentication and user consent in a
                single form,</t>

                <t>make use of CAPTCHAs, or</t>

                <t>use one-time secrets sent out of band to the resource
                owner (e.g., via text or instant message).</t>
              </list> Alternatively, in order to allow the resource owner to
            detect abuse, the authorization server could notify the resource
            owner of any approval by appropriate means, e.g., text or instant
            message, or email.</t>
            -->
          </section>

          <section title="Threat: DoS Attacks That Exhaust Resources">
            <t>
              認可コードやアクセストークンが十分なエントロピーを持っておらず, ユーザーの関与やユーザーごとの認可コード/トークン数の制限無しに自動的にアクセス許可を行う場合, 攻撃者は認可リクエストを繰り返して認可サーバーの認可コード/アクセストークンプールを枯渇させることができる.
            </t>
            <!--
            <t>If an authorization server includes a nontrivial amount of
            entropy in authorization "codes" or access tokens (limiting the
            number of possible codes/tokens) and automatically grants either
            without user intervention and has no limit on codes or access
            tokens per user, an attacker could exhaust the pool of
            authorization "codes" by repeatedly directing the user's browser to
            request authorization "codes" or access tokens.</t>
            -->

            <t>
              対抗策:
            </t>
            <!--
            <t>Countermeasures:</t>
            -->

            <t>
              <list style="symbols">
                <t>
                  認可サーバーはユーザーごとに発行可能なアクセストークンに上限を設けるべきである.
                </t>

                <t>
                  認可サーバーは認可コードに十分なエントロピーを持たせるべきである.
                </t>
              </list>
            </t>
            <!--
            <t><list style="symbols">
                <t>The authorization server should consider limiting the
                number of access tokens granted per user.</t>

                <t>The authorization server should include a nontrivial
                amount of entropy in authorization "codes".</t>
              </list></t>
            -->
          </section>

          <section anchor="semi"
                   title="Threat: DoS Using Manufactured Authorization &quot;codes&quot;"
                   toc="default">
            <t>
              ボットネットを持つ攻撃者であれば, "http://" で始まるリダイレクトURIを収集し, それらにランダムな認可コードを付与してアクセスすることで, 認可サーバーに大量のHTTPSコネクションを集中させることができる.
              (訳注: クライアントのリダイレクトURIは "http://" であり, 認可サーバーの認可エンドポイントは "https://" である点がポイント)
              これは認可サーバーに対するDoSアタックになりうる.
            </t>
            <!--
            <t>An attacker who owns a botnet can locate the redirect URIs of
            clients that listen on HTTP, access them with random
            authorization "codes", and cause a large number of HTTPS
            connections to be concentrated onto the authorization server.
            This can result in a DoS attack on the authorization server.</t>
            -->

            <t>
              この攻撃は, クライアントがCSRF対策を行ったりstateパラメーターを利用していたとしても可能である. (<xref target="section_csrf"></xref>)
              CSRF対策が行われている場合, 攻撃者は正規のCSRFコードやstateパラメーターを取得するため, 追加のHTTPリクエストを行えばよい.
              追加のHTTPリクエストが必要になることで, 攻撃者は2倍のコストを必要とするが, HTTPSとHTTPのコスト比が2倍以上であれば, 攻撃者は認可サーバーに対してDoSアタックを成立させることができる.
              (<xref target="SSL-Latency"></xref> によってHTTPS/HTTPのコスト比は約3.5倍となる)
            </t>
            <!--
            <t>This attack can still be effective even when CSRF defense/the
            "state" parameter (see <xref target="section_csrf"></xref>) is
            deployed on the client side. With such a defense, the attacker
            might need to incur an additional HTTP request to obtain a valid
            CSRF code/"state" parameter. This apparently cuts down the
            effectiveness of the attack by a factor of 2. However, if the
            HTTPS/HTTP cost ratio is higher than 2 (the cost factor is
            estimated to be around 3.5x at <xref target="SSL-Latency"></xref>),
            the attacker still achieves a magnification of resource
            utilization at the expense of the authorization server.</t>
            -->

            <t>
              影響: 認可コードフローのこの特徴により攻撃者が得るメリットには以下のようなものがある.
            </t>
            <!--
            <t>Impact: There are a few effects that the attacker can
            accomplish with this OAuth flow that they cannot easily achieve
            otherwise.</t>
            -->

            <t>
              <list style="numbers">
                <t>
                  Connection Laundering: 正規クライアントが攻撃者と認可サーバーの間に存在するため, 認可サーバーが攻撃者の身元を知るのは困難である.
                  そのため攻撃者のマシンに対するrate limitも困難である.
                  もちろん攻撃者はTorなどの匿名化システムを利用してConnection Launderingを行うこともできるが, その効果は匿名化に用いるシステムによって異なる.
                  一方で, 潜在的に多くのOAuthクライアントがこの攻撃に利用される可能性がある.
                  (訳注: "Connection Laundering" に対する適切な訳語が見つからないが, 「身元を隠して攻撃すること」というニュアンス)
                </t>

                <t>
                  非対称なリソース利用: 攻撃者はHTTPコネクションに必要なコストを負担し, HTTPSコネクションに必要なコストを認可サーバーに与えることができる.
                  複数クライアントにまたがったHTTPSコネクションの発生タイミングも, 比較的簡単にコントロールすることができる.
                  もちろんHTTPのWebページに認可サーバーのHTTPS URLをロードすriframeを仕込み, ユーザーをそのWebページに誘導するなどして同様の攻撃を行うこともできるが, その場合攻撃タイミングのコントロールは困難であろう.
                </t>
              </list>
              対抗策:
            </t>
            <!--
            <t><list style="numbers">
                <t>Connection laundering: With the clients as the relay
                between the attacker and the authorization server, the
                authorization server learns little or no information about the
                identity of the attacker. Defenses such as rate-limiting on
                the offending attacker machines are less effective because it
                is difficult to identify the attacking machines. Although an
                attacker could also launder its connections through an
                anonymizing system such as Tor, the effectiveness of that
                approach depends on the capacity of the anonymizing system. On
                the other hand, a potentially large number of OAuth clients
                could be utilized for this attack.</t>

                <t>Asymmetric resource utilization: The attacker incurs the
                cost of an HTTP connection and causes an HTTPS connection to
                be made on the authorization server; the attacker can
                coordinate the timing of such HTTPS connections across
                multiple clients relatively easily. Although the attacker
                could achieve something similar, say, by including an iFrame
                pointing to the HTTPS URL of the authorization server in an
                HTTP web page and luring web users to visit that page, timing
                attacks using such a scheme may be more difficult, as it seems
                nontrivial to synchronize a large number of users to
                simultaneously visit a particular site under the attacker's
                control.</t>
              </list>Countermeasures:</t>
            -->

            <t>
              <list style="symbols">
                <t>
                  これは完全な対抗策ではないが, クライアントはCSRF対策を行った上で暗号論的擬似乱数生成器により生成されたstateパラメーターを利用すべきである.
                  そしてクライアントはCSRFトークンおよびstateパラメーターの検証が終わってから認可サーバーにアクセスすべきである.
                </t>

                <t>
                  クライアントがシングルサインオンプロトコルやパスワード認証などでユーザーを認証しているのであれば, 不正な認可コードを一定以上入力してきたユーザーのアカウントを一時的に停止すべきである.
                </t>

                <t>
                  認可サーバーは不正な認可コードが送信されたことを示すエラーレスポンスを返し, 一定以上そのようなリクエストを行うクライアントに対してはrate limitやコネクション拒否などの対応を行うべきである.
                </t>
              </list>
            </t>
            <!--
            <t><list style="symbols">
                <t>Though not a complete countermeasure by themselves, CSRF
                defense and the "state" parameter created with secure random
                codes should be deployed on the client side. The client should
                forward the authorization "code" to the authorization server
                only after both the CSRF token and the "state" parameter are
                validated.</t>

                <t>If the client authenticates the user, either through a
                single-sign-on protocol or through local authentication, the
                client should suspend the access by a user account if the
                number of invalid authorization "codes" submitted by this user
                exceeds a certain threshold.</t>

                <t>The authorization server should send an error response to
                the client reporting an invalid authorization "code" and
                rate-limit or disallow connections from clients whose number of
                invalid requests exceeds a threshold.</t>
              </list></t>
            -->
          </section>

          <section title="Threat: Code Substitution (OAuth Login)">
            <t>
              攻撃者は被害者のアイデンティティを用いてアプリケーションやWebサイトにログインすることも考えられる.
              アイデンティティ情報をOAuthにより保護されたサービスのAPIに頼っていると, それが脆弱性につながることがあるのである.
              これは「ソーシャルログイン」と呼ばれるシナリオで散見されるパターンである.
            </t>
            <!--
            <t>An attacker could attempt to log into an application or web
            site using a victim's identity. Applications relying on identity
            data provided by an OAuth protected service API to login users are
            vulnerable to this threat. This pattern can be found in so-called
            "social login" scenarios.</t>
            -->

            <t>
              前提条件として, リソースサーバーがユーザーのアイデンティティを提供するAPIを持っている必要がある.
              クライアントは, OAuthのアクセストークンを使ってこの「アイデンティティAPI」にアクセスし, そのレスポンスに含まれる識別子を使ってユーザーを識別する.
              クライアントはこの一連の操作を持ってユーザーが認証されたものとして扱う.
            </t>
            <!--
            <t>As a prerequisite, a resource server offers an API to obtain
            personal information about a user that could be interpreted as
            having obtained a user identity. In this sense, the client is
            treating the resource server API as an "identity" API. A client
            utilizes OAuth to obtain an access token for the identity API. It
            then queries the identity API for an identifier and uses it to
            look up its internal user account data (login). The client
            assumes that, because it was able to obtain information about the
            user, the user has been authenticated.</t>
            -->

            <t>
              クライアントが認可コードグラントタイプを利用している場合, 攻撃者はクライアントが利用しているのと同じIdentity Provider (IdP) から, ターゲットとなる被害者の認可コードを取得する必要がある.
              このため攻撃者は, 被害者に対して, 同じIdPを通じて悪意あるアプリへログインするよう誘導する.
              (このアプリはIdPにとっては正規クライアントである可能性がある)
              それを受けてIdPはアイデンティティAPIへのアクセス権限を含む認可コードを発行する.
              悪意あるアプリケーションはその認可コードを攻撃者に送り, 攻撃者はそれを受けてターゲットとなるクライアントへのログインフローを開始し, 認可レスポンスに含まれる認可コードを被害者のものに置き換える.
              リソースサーバーに関して言えばaudienceは正常であるため, クライアントは受け取った認可コードをアクセストークンと交換し, アイデンティティAPIにアクセスする.
              しかしながらアイデンティティAPIのレスポンスには被害者の識別子が含まれるため, 攻撃者はターゲットクライアント上の被害者のアカウントにログインできる.
            </t>
            <!--
            <t>If the client uses the grant type "code", the attacker needs to
            gather a valid authorization "code" of the respective victim from
            the same Identity Provider used by the target client application.
            The attacker tricks the victim into logging into a malicious app
            (which may appear to be legitimate to the Identity Provider) using
            the same Identity Provider as the target application. This results
            in the Identity Provider's authorization server issuing an
            authorization "code" for the respective identity API. The malicious
            app then sends this code to the attacker, which in turn triggers a
            login process within the target application. The attacker now
            manipulates the authorization response and substitutes their code
            (bound to their identity) for the victim's code. This code is
            then exchanged by the client for an access token, which in turn is
            accepted by the identity API, since the audience, with respect
            to the resource server, is correct. But since the identifier
            returned
            by the identity API is determined by the identity in the access
            token (issued based on the victim's code), the attacker is logged
            into the target application under the victim's identity.</t>
            -->

            <t>
              影響: 攻撃者は特定のアプリケーションおよびそのアプリケーション内のユーザーデータにアセクセスできる.
            </t>
            <!--
            <t>Impact: The attacker gains access to an application and
            user-specific data within the application.</t>
            -->

            <t>
              対抗策:
            </t>
            <!--
            <t>Countermeasures:</t>
            -->

            <t>
              <list style="symbols">
                <t>
                  すべてのクライアントは, 認可コードをアクセストークンと交換する際, 必ずクライアントIDを提示しなければならない.
                  認可サーバーはその認可コードがそのクライアントに対して発行されたものかどうかを検証しなければならない.
                  可能であればクライアント認証も行うことが望ましい.
                </t>

                <t>
                  クライアントは認証の為にはOpenID (<xref target="OPENID"></xref>) やSAML (<xref target="OASIS.sstc-saml-bindings-1.1"></xref>) といったそれに適したプロトコルを利用すべきである.
                  両プロトコルとも, クライアントに関するaudience制約をサポートしている.
                </t>
              </list>
            </t>
            <!--
            <t><list style="symbols">
                <t>All clients must indicate their client ids with every
                request to exchange an authorization "code" for an access token.
                The authorization server must validate whether the particular
                authorization "code" has been issued to the particular client.
                If possible, the client shall be authenticated beforehand.</t>

                <t>Clients should use an appropriate protocol, such as OpenID
                (cf. <xref target="OPENID"></xref>) or SAML (cf. <xref
                target="OASIS.sstc-saml-bindings-1.1"></xref>) to implement
                user login. Both support audience restrictions on clients.</t>
              </list></t>
            -->
          </section>
        </section>

        <section anchor="implicit_flow" title="Implicit Grant">
          <t>
            implicitグラントタイプフローでは, アクセストークンがリダイレクトURIのフラグメントを通じて直接クライアントに渡される.
            HTTPユーザーエージェントはHTTPサーバーにフラグメント部分を送らないので, トークンはリダイレクトURIが指し示す対象には送られないと想定される.
            よってクライアント・ユーザーエージェント間の通信経路上でアクセストークンを盗聴したりHTTPリファラーヘッダー経由でトークンが漏洩することはない.
          </t>
          <!--
          <t>In the implicit grant type flow, the access token is directly
          returned to the client as a fragment part of the redirect URI. It
          is assumed that the token is not sent to the redirect URI target,
          as HTTP user agents do not send the fragment part of URIs to HTTP
          servers. Thus, an attacker cannot eavesdrop the access token on this
          communication path, and the token cannot leak through HTTP referrer
          headers.</t>
          -->

          <section title="Threat: Access Token Leak in Transport/Endpoints">
            <t>
              トークンが攻撃者に盗聴される可能性がある.
              トークンはリダイレクトURIのフラグメントを通じてサーバーからクライアントに渡される.
              この通信がセキュアで無い場合, トークンが漏洩する.
            </t>
            <!--
            <t>This token might be eavesdropped by an attacker. The token is
            sent from the server to the client via a URI fragment of the
            redirect URI. If the communication is not secured or the endpoint
            is not secured, the token could be leaked by parsing the returned
            URI.</t>
            -->

            <t>
              影響: 攻撃者がトークンの持つ権限を得る.
            </t>
            <!--
            <t>Impact: The attacker would be able to assume the same rights
            granted by the token.</t>
            -->

            <t>
              対抗策:
            </t>
            <!--
            <t>Countermeasures:</t>
            -->

            <t>
              <list style="symbols">
                認可サーバーは (TLSを用いるなど) 認可サーバーからクライアントへのレスポンスの秘匿性を保証すべきである.
                (<xref target="conf_requests"></xref>)
              </list>
            </t>
            <!--
            <t><list style="symbols">
                <t>The authorization server should ensure confidentiality
                (e.g., using TLS) of the response from the authorization server
                to the client (see <xref target="conf_requests"></xref>).</t>
              </list></t>
            -->
          </section>

          <section title="Threat: Access Token Leak in Browser History">
            <t>
              攻撃者はブラウザ履歴からトークンを取得できる.
              これには攻撃者が特定のデバイスにアクセスできる必要がある.
            </t>
            <!--
            <t>An attacker could obtain the token from the browser's history.
            Note that this means the attacker needs access to the particular
            device.</t>
            -->

            <t>
              対抗策:
            </t>
            <!--
            <t>Countermeasures:</t>
            -->

            <t>
              <list style="symbols">
                <t>
                  トークンの有効期間を短くする. (<xref target="short_exp_time"></xref>)
                  トークンのscopeを狭めることも, この攻撃の影響を軽減する可能性がある. (<xref target="limit_scope"></xref>)
                </t>

                <t>
                  レスポンスをキャッシュさせない.
                </t>
              </list>
            </t>
            <!--
            <t><list style="symbols">
                <t>Use short expiry time for tokens (see <xref
                target="short_exp_time"></xref>). Reduced scope of the
                token may reduce the impact of that attack (see <xref
                target="limit_scope"></xref>).</t>

                <t>Make responses non-cacheable.</t>
              </list></t>
            -->
          </section>

          <section anchor="mal_client2"
                   title="Threat: Malicious Client Obtains Authorization">
            <t>
              不正クライアントが詐欺によりトークンを受け取る.
            </t>
            <!--
            <t>A malicious client could attempt to obtain a token by
            fraud.</t>
            -->

            <t>
              クライアント認証の実施を除いては, <xref target="mal_client"></xref> と同様の対策が可能である.
            </t>
            <!--
            <t>The same countermeasures as for <xref
            target="mal_client"></xref> are applicable, except client
            authentication.</t>
            -->
          </section>

          <section title="Threat: Manipulation of Scripts">
            <t>
              攻撃者がクライアントWebサーバーになりすまし, クライアント (のスクリプト) を改竄もしくは置き換える可能性がある.
              これはDNS/ARP Spoofingにより可能になる.
              Webブラウザ上にスクリプト言語で実装されたクライアントが対象となる.
            </t>
            <!--
            <t>A hostile party could act as the client web server and replace
            or modify the actual implementation of the client (script). This
            could be achieved using DNS or ARP spoofing. This applies to
            clients implemented within the web browser in a scripting
            language.</t>
            -->

            <t>
              影響: 攻撃者はユーザーのクレデンシャルを取得し, ユーザーのアイデンティティをも乗っ取り可能であろう.
            </t>
            <!--
            <t>Impact: The attacker could obtain user credential information
            and assume the full identity of the user.</t>
            -->

            <t>
              対抗策:
            </t>
            <!--
            <t>Countermeasures:</t>
            -->

            <t>
              <list style="symbols">
                <t>
                  認可サーバーはスクリプトを配信するサーバーを認証すべきである.
                  (<xref target="server_authn"></xref>)
                </t>

                <t>
                  クライアントは通信系路上でスクリプトが改竄されていないことを保証すべきである.
                  (<xref target="conf_requests"></xref>)
                </t>

                <t>
                  ユーザーごとのone-timeシークレット (client_secretなど) を導入し, スクリプトがサーバーからロードされてから短期間だけ, そのスクリプトだけがそのシークレットを利用できるようにすることも考えられる.
                  これにより, 攻撃者がクライアントサイドのスクリプトをコピーして改竄時に使い回す場合の効率を下げることができる.
                </t>
              </list>
            </t>
            <!--
            <t><list style="symbols">
                <t>The authorization server should authenticate the server
                from which scripts are obtained
                (see <xref target="server_authn"></xref>).</t>

                <t>The client should ensure that scripts obtained have not
                been altered in transport
                (see <xref target="conf_requests"></xref>).</t>

                <t>Introduce one-time, per-use secrets (e.g., "client_secret")
                values that can only be used by scripts in a small time window
                once loaded from a server. The intention would be to reduce
                the effectiveness of copying client-side scripts for re-use in
                an attacker's modified code.</t>
              </list></t>
            -->
          </section>

          <section title="Threat: CSRF Attack against redirect-uri">
            <t>
              CSRF攻撃 (<xref target="section_csrf"></xref>) はimplicitグラントフロー中のリダイレクトURIに対しても実行可能である.
              攻撃者は, 事前に自身のリソースに対するアクセストークンを取得しておき, そのトークンを含むリダイレクトURIを構築することができる.
              その後ユーザーを騙してそのリダイレクトURIにアクセスさせることに成功した場合, クライアントにはそれを防ぐ手だてはない.
              被害者は, そのクライアントに対して発行された攻撃者のアクセストークンと, 紐づけられることになるであろう.
            </t>
            <!--
            <t>CSRF attacks (see <xref target="section_csrf"></xref>) also
            work against the redirect URI used in the implicit grant flow.
            An attacker could acquire an access token to their own protected
            resources. He could then construct a redirect URI and embed
            their access token in that URI. If he can trick the user into
            following the redirect URI and the client does not have
            protection against this attack, the user may have the attacker's
            access token authorized within their client.</t>
            -->

            <t>
              影響: ユーザーは攻撃者のリソースへのアクセスを行う.
              その影響はリソースの種類によって異なるが, 例えばユーザーがプライベートなデータを攻撃者の管理下のリソースにアップロードしてしまうことなどが考えられる.
              OAuthが3rd-partyログインに使われている場合であれば, IdP上の攻撃者のアカウントとクライアント上の被害者アカウントが紐づけられてしまい, 攻撃者が他デバイスからでも簡単にクライアント上の被害者アカウントにログインできてしまうことになる.
            </t>
            <!--
            <t>Impact: The user accesses resources on behalf of the attacker.
            The effective impact depends on the type of resource accessed. For
            example, the user may upload private items to an attacker's
            resources. Or, when using OAuth in 3rd-party login scenarios, the
            user may associate his client account with the attacker's identity
            at the external Identity Provider. In this way, the attacker could
            easily access the victim's data at the client by logging in from
            another device with his credentials at the external Identity
            Provider.</t>
            -->

            <t>
              対抗策:
            </t>
            <!--
            <t>Countermeasures:</t>
            -->

            <t>
              <list style="symbols">
                <t>
                  一連の認可リクエストとアクセストークンを含むリダイレクトレスポンスを紐づけるため, stateパラメーターを用いるべきである.
                  クライアント自身が開始した認可リクエストに対応するリダイレクトレスポンス以外は受け付けないようにする.
                  なおstateパラメーターは推測不可能であり, クライアントはその値を秘匿に保つべきである.
                </t>

                <t>
                  クライアント開発者およびエンドユーザーに, 信頼できないURLを踏まないように教育する.
                </t>
              </list>
            </t>
            <!--
            <t><list style="symbols">
                <t>The "state" parameter should be used to link the
                authorization request with the redirect URI used to deliver
                the access token. This will ensure that the client is not
                tricked into completing any redirect callback unless it is
                linked to an authorization request initiated by the client.
                The "state" parameter should not be guessable, and the client
                should be capable of keeping the "state" parameter secret.</t>

                <t>Client developers and end users can be educated to not
                follow untrusted URLs.</t>
              </list></t>
            -->
          </section>

          <section title="Threat: Token Substitution (OAuth Login)">
            <t>
              攻撃者は被害者のアイデンティティを利用してアプリケーションやWebサイトにログインを試みることがある.
              OAuthで保護されたAPIから取得したアイデンティティデータを使ってユーザー認証を行うアプリケーションが, この脅威の対象となる.
              この攻撃パターンは "social login" と呼ばれるシナリオで見受けられる.
            </t>
            <!--
            <t>An attacker could attempt to log into an application or web
            site using a victim's identity. Applications relying on identity
            data provided by an OAuth protected service API to login users are
            vulnerable to this threat. This pattern can be found in so-called
            "social login" scenarios.</t>
            -->

            <t>
              前提条件として, リソースサーバーがユーザーの個人情報を取得するためのAPIを提供しており, かつその情報を持ってユーザーのアイデンティティが得られたと見なすことができる必要がある.
              これはつまり, クライアントがリソースサーバーのAPIを "Identity" APIとして扱っているということである.
              クライアントは, OAuthのアクセストークンを使ってアイデンティティAPIにアクセスし, ユーザーのアイデンティティを取得した後, 自身が内部で持つユーザーアカウントデータ (ログイン情報) から該当ユーザーを特定する.
              このフローでユーザーの情報を取得できることを根拠として, クライアントは該当ユーザーが認証されたものとして扱う.
            </t>
            <!--
            <t>As a prerequisite, a resource server offers an API to obtain
            personal information about a user that could be interpreted as
            having obtained a user identity. In this sense, the client is
            treating the resource server API as an "identity" API. A client
            utilizes OAuth to obtain an access token for the identity API. It
            then queries the identity API for an identifier and uses it to
            look up its internal user account data (login). The client
            assumes that, because it was able to obtain information about the
            user, the user has been authenticated.</t>
            -->

            <t>
              この攻撃では, 攻撃者は同じIdentity Providerがターゲットのクライアントに向けて発行した, 被害者の正規のアクセストークンを取得する必要がある.
              攻撃者が被害者を騙して, ターゲットクライアントのふりをして不正アプリにログインさせるなどが, その方法となる.
              (この不正アプリはIdentity Providerから見ると, 正規のクライアントのように見える)
              こうすることで, Identity Providerの認可サーバーは該当Identity Provider用のアクセストークンを発行することになる.
              それを受け, 不正アプリは得られたアクセストークンを攻撃者に送信し, それをトリガーとして攻撃者はターゲットアプリのログインフローを開始する.
              ここで攻撃者は認可レスポンスを改竄し, 自身のアクセストークンの代わりに被害者のアクセストークンをレスポンスに含める.
              このトークンは, リソースサーバーに関しては正規のaudienceを持つため, アイデンティティAPIで受け入れられる.
              しかしアイデンティティAPIから返されるユーザー識別子は被害者のものであるため, 攻撃者はターゲットアプリに被害者としてログインできてしまう.
            </t>
            <!--
            <t>To succeed, the attacker needs to gather a valid access token
            of the respective victim from the same Identity Provider used by
            the target client application. The attacker tricks the victim into
            logging into a malicious app (which may appear to be legitimate to
            the Identity Provider) using the same Identity Provider as the
            target application. This results in the Identity Provider's
            authorization server issuing an access token for the respective
            identity API. The malicious app then sends this access token to
            the attacker, which in turn triggers a login process within the
            target application. The attacker now manipulates the authorization
            response and substitutes their access token (bound to their
            identity) for the victim's access token. This token is accepted by
            the identity API, since the audience, with respect to the resource
            server, is correct. But since the identifier returned by the
            identity API is determined by the identity in the access token,
            the attacker is logged into the target application under the
            victim's identity.</t>
            -->

            <t>
              影響: 攻撃者は, そのアプリケーション自体へのアクセス, および被害者がアプリケーション内で持つユーザーデータへのアクセスを取得することになる.
            </t>
            <!--
            <t>Impact: The attacker gains access to an application and
            user-specific data within the application.</t>
            -->

            <t>
              対抗策:
            </t>
            <!--
            <t>Countermeasures:</t>
            -->

            <t>
              <list style="symbols">
                <t>
                  クライアントは, OpenID (<xref target="OPENID"></xref>) や SAML (<xref target="OASIS.sstc-saml-bindings-1.1"></xref>) など, ユーザー認証に適切なプロトコルを利用するべきである.
                  ここであげた2つのプロトコルは, どちらもクライアント上でのaudience制約をサポートする.
                </t>
              </list>
            </t>
            <!--
            <t><list style="symbols">
                <t>Clients should use an appropriate protocol, such as OpenID
                (cf. <xref target="OPENID"></xref>) or SAML (cf. <xref
                target="OASIS.sstc-saml-bindings-1.1"></xref>) to implement
                user login. Both support audience restrictions on clients.</t>
              </list></t>
            -->
          </section>
        </section>

        <section anchor="pwd_flow" title="Resource Owner Password Credentials">
          <t>
            リソースオーナーパスワードクレデンシャルグラントタイプ (<xref target="RFC6749"></xref> Section 4.3) は, レガシーシステムからの移行のためなどにしばしば利用される.
            このグラントタイプでは, クライアントは自身のクレデンシャルの他に, エンドユーザーのIDとパスワードにも直接アクセスし, それらを使ってアクセストークンを取得する.
            このグラントタイプはUID/パスワードアンチパターンに当てはまるため, 他のグラントタイプより高リスクである.
            さらに, 認可プロセスはユーザーのコントロール下にないため, このグラントタイプを利用するクライアントはscopeによる制約を受けず, 潜在的にはユーザー自身と同じ権限を持ちうる.
            (訳注: ID & パスワードを教えた時点でおしまいということ)
            認可ステップが存在しないため, トークンの無効化機能もバイパスされうる.
          </t>
          <!--
          <t>The resource owner password credentials grant type
          (see <xref target="RFC6749"></xref>, Section 4.3), often
          used for legacy/migration reasons, allows a client to request an
          access token using an end-user's user id and password along with its
          own credential. This grant type has higher risk because it maintains
          the UID/password anti-pattern. Additionally, because the user does
          not have control over the authorization process, clients using this
          grant type are not limited by scope but instead have potentially
          the same capabilities as the user themselves. As there is no
          authorization step, the ability to offer token revocation is
          bypassed.</t>
          -->

          <t>
            往々にして2つ以上のサービスで同じパスワードを使うというケースが存在するため, このアンチパターンは提供されたクレデンシャルにアクセス可能ないかなるサービスをもリスクにさらす可能性がある.
            さらに, 容易に同じ主体であると推測できる情報 (joe@example.com と joe@example.net のペアなど) から, 同じパスワードが違う場所で利用されていることを容易に推測可能なケースもありうる.
          </t>
          <!--
          <t>Because passwords are often used for more than 1 service, this
          anti-pattern may also put at risk whatever else is accessible with
          the supplied credential. Additionally, any easily derived equivalent
          (e.g., joe@example.com and joe@example.net) might easily allow
          someone to guess that the same password can be used elsewhere.</t>
          -->

          <t>
            影響: リソースサーバーは, 特定のクライアントに紐づけられたアクセストークンベースでしかscopeの区別を付けることができない.
            クライアントは長期間有効なトークンを取得し攻撃者にそれを送信することもできる.
            クライアントおよびエンドポイントにいる主体は, ユーザーIDとパスワードを盗聴可能である.
          </t>
          <!--
          <t>Impact: The resource server can only differentiate scope based on
          the access token being associated with a particular client. The
          client could also acquire long-lived tokens and pass them up to an
          attacker's web service for further abuse. The client, eavesdroppers,
          or endpoints could eavesdrop the user id and password.</t>
          -->

          <t>
            対抗策:
          </t>
          <!--
          <t>Countermeasures:</t>
          -->

          <t>
            <list style="symbols">
              <t>
                移行のため以外の目的でこのグラントタイプを利用するのはなるべく避ける.
              </t>

              <t>
                認可サーバーはトークンリフレッシュ時に毎回リフレッシュトークンに紐づくクライアントIDを検証すべきである.
                (<xref target="binding_refresh_client_id"></xref>)
              </t>

              <t>
                OAuth Core仕様にあるように, 認可サーバーはTLSのようなトランスポートレイヤーのメカニズムによって通信が保護されていることを保証しなければならない.
                (<xref target="conf_requests"></xref>)
              </t>

              <t>
                各サービスは, ユーザーに複数のサービスで同じパスワードを使うことの危険性を教えるべきである.
              </t>

              <t>
                リソースオーナーパスワードクレデンシャルグラントの利用を, 同じ組織が運営するクライアントアプリケーションに限定する.
              </t>
            </list>
          </t>
          <!--
          <t><list style="symbols">
              <t>Except for migration reasons, minimize use of this grant
              type.</t>

              <t>The authorization server should validate the client id
              associated with the particular refresh token with every refresh
              request (<xref target="binding_refresh_client_id"></xref>).</t>

              <t>As per the core OAuth specification, the authorization server must
              ensure that these transmissions are protected using
              transport-layer mechanisms such as TLS
              (see <xref target="conf_requests"></xref>).</t>

              <t>Rather than encouraging users to use a UID and password,
              service providers should instead encourage users not to use the
              same password for multiple services.</t>

              <t>Limit use of resource owner password credential grants to
              scenarios where the client application and the authorizing
              service are from the same organization.</t>
            </list></t>
          -->

          <section title="Threat: Accidental Exposure of Passwords at Client Site">
            <t>
              クライアントのセキュリティが不十分な場合, 攻撃者や内部犯行者がユーザーのパスワードを取得する可能性がある.
            </t>
            <!--
            <t>If the client does not provide enough protection, an attacker
            or disgruntled employee could retrieve the passwords for a
            user.</t>
            -->

            <t>
              対抗策:
            </t>
            <!--
            <t>Countermeasures:</t>
            -->

            <t>
              <list style="symbols">
                <t>
                  クライアントがリソースオーナークレデンシャルにアクセスすることのない, 他のフローを利用する.
                </t>

                <t>
                  平文でクレデンシャルを扱うのではなく, ダイジェスト認証を利用する.
                </t>

                <t>
                  ログに含まれるアクセストークンを解読困難にする.
                </t>
              </list>
            </t>
            <!--
            <t><list style="symbols">
                <t>Use other flows that do not rely on the client's
                cooperation for secure resource owner credential handling.</t>

                <t>Use digest authentication instead of plaintext credential
                processing.</t>

                <t>Obfuscate passwords in logs.</t>
              </list></t>
            -->
          </section>

          <section title="Threat: Client Obtains Scopes without End-User Authorization">
            <t>
              すべてのリソースオーナーとのインタラクションは, クライアントによって行われるため, 意図の有無にかかわらず, リソースオーナーが認識しないもしくは意図していなかったscopeを持つトークンが発行される可能性がある.
              例えば, リソースオーナーが, クライアントはメディアストレージへのread-onlyアクセスのみを必要としていると思ったにも関わらず, クライアントは実際にはフルアクセス権限をリクエストしていた, というようなこともありうる.
            </t>
            <!--
            <t>All interaction with the resource owner is performed by the
            client. Thus it might, intentionally or unintentionally, happen
            that the client obtains a token with scope unknown for, or
            unintended by, the resource owner. For example, the resource owner
            might think the client needs and acquires read-only access to its
            media storage only but the client tries to acquire an access token
            with full access permissions.</t>
            -->

            <t>
              対抗策:
            </t>
            <!--
            <t>Countermeasures:</t>
            -->

            <t>
              <list style="symbols">
                <t>
                  クライアントがリソースオーナークレデンシャルにアクセスすることのない, 他のフローを利用する.
                </t>

                <t>
                  認可サーバーはこのフローで発行されたアクセストークンのscopeを制限することができる.
                  (<xref target="limit_scope"></xref>)
                  もし特定のクライアントが信頼でき, かつセキュアに認証可能な場合は, そのような制約を設けないこともある.
                  リソースオーナーが事前に (設定画面などで) このフローで取得できるscopeの上限を設定することも検討可能である.
                </t>

                <t>
                  認可サーバーは適切な経路 (emailなど) でリソースオーナーにグラント発行通知を送ることもできる.
                  (<xref target="informed"></xref>)
                </t>
              </list>
            </t>
            <!--
            <t><list style="symbols">
                <t>Use other flows that do not rely on the client's
                cooperation for resource owner interaction.</t>

                <t>The authorization server may generally restrict the scope
                of access tokens (<xref target="limit_scope"></xref>) issued
                by this flow. If the particular client is trustworthy and can
                be authenticated in a reliable way, the authorization server
                could relax that restriction. Resource owners may prescribe
                (e.g., in their preferences) what the maximum scope is for
                clients using this flow.</t>

                <t>The authorization server could notify the resource owner by
                an appropriate medium, e.g., email, of the grant issued (see
                <xref target="informed"></xref>).</t>
              </list></t>
            -->
          </section>

          <section title="Threat: Client Obtains Refresh Token through Automatic Authorization">
            <t>
              すべてのリソースオーナーとのインタラクションは, クライアントによって行われるため, 意図の有無にかかわらず, リソースオーナーの意思に反してクライアントが長期間有効なリフレッシュトークンを取得する可能性がある.
            </t>
            <!--
            <t>All interaction with the resource owner is performed by the
            client. Thus it might, intentionally or unintentionally, happen
            that the client obtains a long-term authorization represented by a
            refresh token even if the resource owner did not intend so.</t>
            -->

            <t>
              対抗策:
            </t>
            <!--
            <t>Countermeasures:</t>
            -->

            <t>
              <list style="symbols">
                <t>
                  クライアントがリソースオーナークレデンシャルにアクセスすることのない, 他のフローを利用する.
                </t>

                <t>
                  認可サーバーはこのフローではリフレッシュトークンの発行を禁止することもできる.
                  (<xref target="restricted_refresh"></xref>)
                  もし特定のクライアントが信頼でき, かつセキュアに認証可能な場合は, そのような制約を設けないこともある.
                  リソースオーナーに (設定画面などで) このフローでのリフレッシュトークンの発行を禁止させることも検討可能である.
                </t>

                <t>
                  認可サーバーは適切な経路 (emailなど) でリソースオーナーにグラント発行通知を送ることもできる.
                  (<xref target="informed"></xref>)
                </t>
              </list>
            </t>
            <!--
            <t><list style="symbols">
                <t>Use other flows that do not rely on the client's
                cooperation for resource owner interaction.</t>

                <t>The authorization server may generally refuse to issue
                refresh tokens in this flow (see <xref
                target="restricted_refresh"></xref>). If the particular client
                is trustworthy and can be authenticated in a reliable way (see
                client authentication), the authorization server could relax
                that restriction. Resource owners may allow or deny (e.g., in
                their preferences) the issuing of refresh tokens using this
                flow as well.</t>

                <t>The authorization server could notify the resource owner by
                an appropriate medium, e.g., email, of the refresh token issued
                (see <xref target="informed"></xref>).</t>
              </list></t>
            -->
          </section>

          <section title="Threat: Obtaining User Passwords on Transport">
            <t>
              攻撃者が通信を盗聴してユーザーのパスワードを盗むことも考えられる.
            </t>
            <!--
            <t>An attacker could attempt to eavesdrop the transmission of
            end-user credentials with the grant type &bdquo;password&ldquo;
            between the client and server.</t>
            -->

            <t>
              影響: 1人のエンドユーザーのパスワード漏洩
            </t>
            <!--
            <t>Impact: Disclosure of a single end-user's password.</t>
            -->

            <t>
              対抗策:
            </t>
            <!--
            <t>Countermeasures:</t>
            -->

            <t>
              <list style="symbols">
                <t>
                  リクエストの秘匿性を保証する.
                  (<xref target="conf_requests"></xref>)
                </t>

                <t>
                  平文でクレデンシャルを送信することのない認証手段を用いる.
                  (HMACなど)
                </t>
              </list>
            </t>
            <!--
            <t><list style="symbols">
                <t>Ensure confidentiality of requests
                (<xref target="conf_requests"></xref>).</t>

                <t>Use alternative authentication means that do not require the
                sending of plaintext credentials over the wire
                (e.g., Hash-based Message Authentication Code).</t>
              </list></t>
            -->
          </section>

          <section title="Threat: Obtaining User Passwords from Authorization Server Database">
            <t>
              データベースへの不正アクセスやSQLインジェクション攻撃などにより, 攻撃者が認可サーバーのデータベースから有効なユーザー名とパスワードのペアを盗み出すことも考えられる.
            </t>
            <!--
            <t>An attacker may obtain valid username/password combinations
            from the authorization server's database by gaining access to the
            database or launching a SQL injection attack.</t>
            -->

            <t>
              影響: 全ユーザーのユーザー名 & パスワードペアの漏洩.
              これは, 同じクレデンシャルを他サービスで利用しているケースなどでは, 認可サーバーのドメインを超えて影響を与える.
            </t>
            <!--
            <t>Impact: Disclosure of all username/password combinations. The
            impact may exceed the domain of the authorization server, since
            many users tend to use the same credentials on different
            services.</t>
            -->

            <t>
              対抗策:
            </t>
            <!--
            <t>Countermeasures:</t>
            -->

            <t>
              <list style="symbols">
                <t>
                  クレデンシャルストレージ保護のためのベストプラクティスに従う.
                  (<xref target="cred_storage_prot"></xref>)
                </t>
              </list>
            </t>
            <!--
            <t><list style="symbols">
                <t>Enforce credential storage protection best practices
                (<xref target="cred_storage_prot"></xref>).</t>
              </list></t>
            -->
          </section>

          <section title="Threat: Online Guessing">
            <t>
              攻撃者が正規のユーザー名 & パスワードペアを推測し, passwordグラントとして利用することも考えられる.
            </t>
            <!--
            <t>An attacker may try to guess valid username/password
            combinations using the grant type "password&ldquo;.</t>
            -->

            <t>
              影響: 1人のユーザー名 & パスワードペアの漏洩.
            </t>
            <!--
            <t>Impact: Revelation of a single username/password
            combination.</t>
            -->

            <t>
              対抗策:
            </t>
            <!--
            <t>Countermeasures:</t>
            -->

            <t>
              <list style="symbols">
                <t>
                  セキュアパスワードポリシーに従う.
                  (<xref target="pwd_policy"></xref>)
                </t>

                <t>
                  アカウントロック. (<xref target="lock_accounts"></xref>)
                </t>

                <t>
                  tar pitを利用する. (<xref target="tar_pit"></xref>)
                </t>

                <t>
                  CAPTCHAを利用する. (<xref target="captchas"></xref>)
                </t>

                <t>
                  passwordグラントを利用しない.
                </t>

                <t>
                  クライアント認証という他の認証要素によって, 攻撃を邪魔することもある.
                  (<xref target="client_aa"></xref>)
                </t>
              </list>
            </t>
            <!--
            <t><list style="symbols">
                <t>Utilize secure password policy
                (<xref target="pwd_policy"></xref>).</t>

                <t>Lock accounts (<xref target="lock_accounts"></xref>).</t>

                <t>Use tar pit (<xref target="tar_pit"></xref>).</t>

                <t>Use CAPTCHAs (<xref target="captchas"></xref>).</t>

                <t>Consider not using the grant type "password&ldquo;.</t>

                <t>Client authentication (see <xref
                target="client_aa"></xref>) will provide another
                authentication factor and thus hinder the attack.</t>
              </list></t>
            -->
          </section>
        </section>

        <section title="Client Credentials">
          <t>
            クライアントクレデンシャル (<xref target="RFC6749"></xref> Section 3) は, クライアント認証のための手段 (client secretのマッチングなど) と紐づいた識別子 (secretではない) により構成される.
            このグラントタイプに対する脅威は, <xref target="pwd_flow"></xref> で述べられたものと類似している.
          </t>
          <!--
          <t>Client credentials (see <xref target="RFC6749"></xref>,
          Section 3) consist of an identifier (not secret) combined with an
          additional means (such as a matching client secret) of
          authenticating a client. The threats to this grant type are similar
          to those described in <xref target="pwd_flow"></xref>.</t>
          -->
        </section>
      </section>

      <section title="Refreshing an Access Token">
        <section title="Threat: Eavesdropping Refresh Tokens from Authorization Server">
          <t>
            攻撃者が認可サーバー・クライアント間の通信を盗聴しリフレッシュトークンを盗み出す可能性がある.
          </t>
          <!--
          <t>An attacker may eavesdrop refresh tokens when they are
          transmitted from the authorization server to the client.</t>
          -->

          <t>
            対抗策:
          </t>
          <!--
          <t>Countermeasures:</t>
          -->

          <t>
            <list style="symbols">
              <t>
                OAuth Core仕様にあるように, 認可サーバーは通信がTLSのようなトランスポートレイヤーメカニズムによって保護されていることを保証しなければならない.
                (<xref target="conf_requests"></xref>)
              </t>

              <t>
                もしend-to-endの機密性が確保できない場合は, 発行するアクセストークンのscopeを狭め有効期限を短くすることで, 漏洩時のリスクを軽減できる.
                (<xref target="limit_scope"></xref>, <xref target="short_exp_time"></xref>)
              </t>
            </list>
          </t>
          <!--
          <t><list style="symbols">
              <t>As per the core OAuth spec, the authorization servers must
              ensure that these transmissions are protected using
              transport-layer mechanisms such as TLS
              (see <xref target="conf_requests"></xref>).</t>

              <t>If end-to-end confidentiality cannot be guaranteed, reducing
              scope (see <xref target="limit_scope"></xref>) and expiry time
              (see <xref target="short_exp_time"></xref>) for issued access
              tokens can be used to reduce the damage in case of leaks.</t>
            </list></t>
          -->
        </section>

        <section title="Threat: Obtaining Refresh Token from Authorization Server Database">
          <t>
            この脅威は, 認可サーバーがリフレッシュトークンをhandleとしてデータベースに保存している場合に起こりうる.
            攻撃者はデータベースへのアクセス権を不正取得したり, SQLインジェクション攻撃によって, 認可サーバーのデータベースからリフレッシュトークンを取得する可能性がある.
          </t>
          <!--
          <t>This threat is applicable if the authorization server stores
          refresh tokens as handles in a database. An attacker may obtain
          refresh tokens from the authorization server's database by gaining
          access to the database or launching a SQL injection attack.</t>
          -->

          <t>
            影響: 全リフレッシュトークンの漏洩.
          </t>
          <!--
          <t>Impact: Disclosure of all refresh tokens.</t>
          -->

          <t>
            対抗策:
          </t>
          <!--
          <t>Countermeasures:</t>
          -->

          <t>
            <list style="symbols">
              <t>
                クレデンシャルストレージのベストプラクティスに従う.
                (<xref target="cred_storage_prot"></xref>)
              </t>

              <t>
                攻撃者がクライアントIDとシークレットを盗めないことが想定できる場合は, トークンをクライアントIDと紐付ける.
                (<xref target="bind_token_client_id"></xref>)
              </t>
            </list>
          </t>
          <!--
          <t><list style="symbols">
              <t>Enforce credential storage protection best practices
              (<xref target="cred_storage_prot"></xref>).</t>

              <t>Bind token to client id, if the attacker cannot obtain the
              required id and secret
              (<xref target="bind_token_client_id"></xref>).</t>
            </list></t>
          -->
        </section>

        <section title="Threat: Obtaining Refresh Token by Online Guessing">
          <t>
            攻撃者が有効なリフレッシュトークンの値を推測し, それをrefresh_tokenグラントとして用いてアクセストークンを取得する可能性がある.
          </t>
          <!--
          <t>An attacker may try to guess valid refresh token values and send
          it using the grant type &bdquo;refresh_token&ldquo; in
          order to obtain a valid access token.</t>
          -->

          <t>
            影響: 単一のリフレッシュトークンおよびそれを使って取得できるアクセストークンの漏洩.
          </t>
          <!--
          <t>Impact: Exposure of a single refresh token and derivable access
          tokens.</t>
          -->

          <t>
            対抗策:
          </t>
          <!--
          <t>Countermeasures:</t>
          -->

          <t>
            <list style="symbols">
              <t>
                handleベースデザインの場合はこちら. (<xref target="high_entropy"></xref>)
              </t>

              <t>
                assertionベースデザインの場合はこちら. (<xref target="signed_tokens"></xref>)
              </t>

              <t>
                トークンをクライアントIDと紐づける.
                これにより攻撃者はトークンと紐づいたクライアントIDをも推測しなければならなくなる.
                (<xref target="bind_token_client_id"></xref>)
              </t>

              <t>
                クライアント認証を行う.
                これによりさらに攻撃者の推測項目が増える.
                (<xref target="depl_specific_secretes"></xref>)
              </t>
            </list>
          </t>
          <!--
          <t><list style="symbols">
              <t>For handle-based designs
              (<xref target="high_entropy"></xref>).</t>

              <t>For assertion-based designs
              (<xref target="signed_tokens"></xref>).</t>

              <t>Bind token to client id, because the attacker would guess the
              matching client id, too
              (see <xref target="bind_token_client_id"></xref>).</t>

              <t>Authenticate the client; this adds another element that
              the attacker has to guess
              (see <xref target="depl_specific_secretes"></xref>).</t>
            </list></t>
          -->
        </section>

        <section title="Threat: Refresh Token Phishing by Counterfeit Authorization Server">
          <t>
            攻撃者が認可サーバーへのリクエストをプロキシし, 有効なリフレッシュトークンを取得しようとする可能性がある.
            認可サーバーURLはクライアント開発時で既知であるか, 少なくとも既知のリソースサーバーから取得できる状態にあることが想定されるため, 攻撃者は攻撃のためある程度のスプーフィングを必要とする.
          </t>
          <!--
          <t>An attacker could try to obtain valid refresh tokens by proxying
          requests to the authorization server. Given the assumption that the
          authorization server URL is well-known at development time or can at
          least be obtained from a well-known resource server, the attacker
          must utilize some kind of spoofing in order to succeed.</t>
          -->

          <t>
            対抗策:
          </t>
          <!--
          <t>Countermeasures:</t>
          -->

          <t>
            <list style="symbols">
              <t>
                サーバー認証. (<xref target="server_authn"></xref>)
              </t>
            </list>
          </t>
          <!--
          <t><list style="symbols">
              <t>Utilize server authentication
              (as described in <xref target="server_authn"></xref>).</t>
            </list></t>
          -->
        </section>
      </section>

      <section title="Accessing Protected Resources">
        <section title="Threat: Eavesdropping Access Tokens on Transport">
          <t>
            攻撃者がクライアント・リソースサーバー間の通信系路上で有効なアクセストークンを取得する可能性がある.
            アクセストークンは認可サーバーとリソースサーバーの間で共有されるシークレット情報であるため, 他のクレデンシャル (エンドユーザーパスワードなど) と同じような保護が必要である.
          </t>
          <!--
          <t>An attacker could try to obtain a valid access token on transport
          between the client and resource server. As access tokens are shared
          secrets between the authorization server and resource server,
          they should be
          treated with the same care as other credentials (e.g., end-user
          passwords).</t>
          -->

          <t>
            対抗策:
          </t>
          <!--
          <t>Countermeasures:</t>
          -->

          <t>
            <list style="symbols">
              <t>
                Bearerトークンとして送信されるアクセストークンは, セキュアでないチャネルで平文で送るべきではない.
                OAuth Core仕様にあるように, アクセストークン送信時はTLSなどのトランスポートメカニズムによって通信を保護しなければならない.
                (<xref target="conf_requests"></xref>)
              </t>

              <t>
                トークンの有効期限を短くすることで, 漏洩時のリスクを軽減できる.
                (<xref target="short_exp_time"></xref>)
              </t>

              <t>
                アクセストークンをクライアント識別子と紐付け, クライアントにリソースサーバーに対してその所有権を証明させる.
                (<xref target="authn_requests"></xref>)
              </t>
            </list>
          </t>
          <!--
          <t><list style="symbols">
              <t>Access tokens sent as bearer tokens should not be sent in
              the clear over an insecure channel. As per the core OAuth spec,
              transmission of access tokens must be protected using
              transport-layer mechanisms such as TLS (see <xref
              target="conf_requests"></xref>).</t>

              <t>A short lifetime reduces impact in case tokens are
              compromised (see <xref target="short_exp_time"></xref>).</t>

              <t>The access token can be bound to a client's identifier and
              require the client to prove legitimate ownership of the token to
              the resource server (see <xref
              target="authn_requests"></xref>).</t>
            </list></t>
          -->
        </section>

        <section title="Threat: Replay of Authorized Resource Server Requests">
          <t>
            攻撃者がユーザーデータを取得/改変/破壊するため, 有効なリクエストをリプレイする可能性がある.
          </t>
          <!--
          <t>An attacker could attempt to replay valid requests in order to
          obtain or to modify/destroy user data.</t>
          -->

          <t>
            対抗策:
          </t>
          <!--
          <t>Countermeasures:</t>
          -->

          <t>
            <list style="symbols">
              <t>
                リソースサーバーはTLSのようなトランスポートレイヤーメカニズムを用いて, この攻撃を防ぐべきである.
                (<xref target="conf_requests"></xref>)
                これにより攻撃者は正規のリクエストをキャプチャできなくなる.
              </t>

              <t>
                代替策として, リソースサーバーは署名付きリクエスト (<xref target="signed_requests"></xref>) をnonceとtimestampと共に利用し, 各リクエストをユニークに識別することができる.
                リソースサーバーはこの情報によりリプレイを検知し, リクエストを拒否すべきである.
              </t>
            </list>
          </t>
          <!--
          <t><list style="symbols">
              <t>The resource server should utilize transport security
              measures (e.g., TLS) in order to prevent such attacks (see <xref
              target="conf_requests"></xref>). This would prevent the attacker
              from capturing valid requests.</t>

              <t>Alternatively, the resource server could employ signed
              requests (see <xref target="signed_requests"></xref>) along with
              nonces and timestamps in order to uniquely identify requests.
              The resource server should detect and refuse every replayed
              request.</t>
            </list></t>
          -->
        </section>

        <section title="Threat: Guessing Access Tokens">
          <t>
            トークンがhandleの場合, 攻撃者は他のアクセストークンから得られる情報を頼りにアクセストークンの値を推測する可能性がある.
          </t>
          <!--
          <t>Where the token is a handle, the attacker may attempt to
          guess the access token values based on knowledge they have from
          other access tokens.</t>
          -->

          <t>
            影響: 単一ユーザーのデータにアクセスされる.
          </t>
          <!--
          <t>Impact: Access to a single user's data.</t>
          -->

          <t>
            対抗策:
          </t>
          <!--
          <t>Countermeasures:</t>
          -->

          <t>
            <list style="symbols">
              <t>
                handleトークンには十分なエントロピーを持たせ, 有効な値の推測を不可能にするべきである.
                (<xref target="high_entropy"></xref>)
              </t>

              <t>
                assertion (もしくはself-contained) トークンの内容は, 電子署名により保護すべきである.
                (<xref target="signed_tokens"></xref>)
              </t>

              <t>
                アクセストークン有効期限の短縮は, さらにいっそうセキュリティを強化する.
                (<xref target="exp_time" format="counter"></xref> & <xref target="short_exp_time" format="counter"></xref>)
              </t>
            </list>
          </t>
          <!--
          <t><list style="symbols">
              <t>Handle tokens should have a reasonable level of entropy
              (see <xref target="high_entropy"></xref>) in order to make
              guessing a valid token value infeasible.</t>

              <t>Assertion (or self-contained token) token contents should
              be protected by a digital signature
              (see <xref target="signed_tokens"></xref>).</t>

              <t>Security can be further strengthened by using a short access
              token duration (see Sections <xref target="exp_time" format="counter"></xref> and <xref target="short_exp_time" format="counter"></xref>).</t>
            </list></t>
          -->
        </section>

        <section title="Threat: Access Token Phishing by Counterfeit Resource Server">
          <t>
            攻撃者が特定のリソースサーバーを装って, 特定の認可サーバーから発行されたアクセストークンを受け取る可能性がある.
            クライアントが有効なアクセストークンをこの偽リソースサーバーに送ると, サーバーはリソースオーナーの認可のもと他のサービスにアクセスできるようになる.
          </t>
          <!--
          <t>An attacker may pretend to be a particular resource server and to
          accept tokens from a particular authorization server. If the client
          sends a valid access token to this counterfeit resource server, the
          server in turn may use that token to access other services on behalf
          of the resource owner.</t>
          -->

          <t>
            対抗策:
          </t>
          <!--
          <t>Countermeasures:</t>
          -->

          <t>
            <list style="symbols">
              <t>
                クライアントは, セキュアチャネルの有無に関わらず, 未知のリソースサーバーに対して認証済リクエストを送るべきでない.
                リソースサーバーURLがクライアントに対して既知な場合は, セキュアチャネルを利用することでリソースサーバーの認証が可能である.
                (<xref target="server_authn"></xref>)
              </t>

              <t>
                クライアントがアクセスするリソースサーバーのエンドポイントURLを, アクセストークンと関連づけ, 正規のリソースサーバーではその関連を検証する.
                (audienceフィールドなどを利用)
                エンドポイントURLのバリデーションポリシーは, 厳密な完全一致でもよいし, ホストのみの一致などのラフな方法でもよい.
                この手法では, 認可サーバーがリソースサーバーエンドポイントURLを認可プロセス中に知る必要がある.
              </t>

              <t>
                アクセストークンをクライアントと関連づけ, リソースサーバーへのリクエスト時にクライアントを認証する.
                (典型的には, 潜在的攻撃者にシークレットを漏らさないため, 署名を利用する)
                これにより, 偽サーバーはリソースサーバーに対して正しく認証を行うことができなくなると想定できるので, 攻撃を防ぐことができる.
                (<xref target="authn_requests"></xref>)
              </t>

              <t>
                トークンのscopeを狭めたり, トークンの有効範囲を特定のリソースサーバーに限定するなど.
                ( <xref target="limit_scope"></xref>, <xref target="bind_token_rs"></xref>)
              </t>
            </list>
          </t>
          <!--
          <t><list style="symbols">
              <t>Clients should not make authenticated requests with an access
              token to unfamiliar resource servers, regardless of the presence
              of a secure channel. If the resource server URL is well-known to
              the client, it may authenticate the resource servers (see <xref
              target="server_authn"></xref>).</t>

              <t>Associate the endpoint URL of the resource server the client
              talked to with the access token (e.g., in an audience field) and
              validate the association at a legitimate resource server.
              The endpoint
              URL validation policy may be strict (exact match) or more
              relaxed (e.g., same host). This would require telling the
              authorization server about the resource server endpoint URL in
              the authorization process.</t>

              <t>Associate an access token with a client and authenticate the
              client with resource server requests (typically via a signature,
              in order to not disclose a secret to a potential attacker). This
              prevents the attack because the counterfeit server is assumed to
              lack the capability to correctly authenticate on behalf of the
              legitimate client to the resource server (<xref
              target="authn_requests"></xref>).</t>

              <t>Restrict the token scope (see <xref
              target="limit_scope"></xref>) and/or limit the token to a
              certain resource server (<xref
              target="bind_token_rs"></xref>).</t>
            </list></t>
          -->
        </section>

        <section title="Threat: Abuse of Token by Legitimate Resource Server or Client">
          <t>
            正規のリソースサーバーが別のリソースサーバーにアクセスしようとする可能性がある.
            同じように, クライアントもまた取得したトークンを別のリソースサーバーに対して使うこともありうる.
          </t>
          <!--
          <t>A legitimate resource server could attempt to use an access token
          to access another resource server. Similarly, a client could try to
          use a token obtained for one server on another resource server.</t>
          -->

          <t>
            対抗策:
          </t>
          <!--
          <t>Countermeasures:</t>
          -->

          <t>
            <list style="symbols">
              <t>
                トークン有効範囲を特定のリソースサーバーに限定するべきである.
                (<xref target="bind_token_rs"></xref>)
              </t>
            </list>
          </t>
          <!--
          <t><list style="symbols">
              <t>Tokens should be restricted to particular resource servers
              (see <xref target="bind_token_rs"></xref>).</t>
            </list></t>
          -->
        </section>

        <section title="Threat: Leak of Confidential Data in HTTP Proxies">
          <t>
            <xref target="RFC6749"/> にあるOAuth HTTP認証スキームはオプショナルである.
            しかしながら, <xref target="RFC2616"></xref> は認証コンテキストの識別のため Authorization および WWW&nbhy;Authenticate ヘッダーに依存し, それによってセキュリティを担保している.
            特にプロキシやキャッシュなどにより, これらのヘッダーを利用しないリクエストが適切に保護されないケースがありうる.
            例えば, プライベートな認証コンテキストがパブリックにアクセス可能な状態でキャッシュされるといったことが考えられる.
          </t>
          <!--
          <t>An OAuth HTTP authentication scheme as discussed
          in <xref target="RFC6749"/> is optional.
          However, <xref target="RFC2616"></xref> relies on the
          Authorization and WWW&nbhy;Authenticate headers to distinguish
          authenticated content so that it can be protected. Proxies and
          caches, in particular, may fail to adequately protect requests not
          using these headers. For example, private authenticated content may
          be stored in (and thus be retrievable from) publicly accessible
          caches.</t>
          -->

          <t>
            対抗策:
          </t>
          <!--
          <t>Countermeasures:</t>
          -->

          <t>
            <list style="symbols">
              <t>
                OAuth HTTP認証スキーム (<xref target="authz_header"></xref>) を利用しないクライアントやリソースサーバーは, Cache-Controlヘッダーを使って上記のリスクを最小化すべきである.
                上記のようなクライアントは, Cache&nbhy;Control ヘッダーに "no-store" <xref target="RFC2616"></xref> をセットすべきである.
                また上記のようなリソースサーバーは, サクセスレスポンス (2xxステータス) の Cache-Control ヘッダーに "private" <xref target="RFC2616"></xref>をセットすべきである.
              </t>

              <t>
                アクセストークンのscopeと有効期限を制限し, 漏洩時のリスクを軽減する.
                (<xref target="limit_scope"></xref>, <xref target="short_exp_time"></xref>)
              </t>
            </list>
          </t>
          <!--
          <t><list style="symbols">
              <t>Clients and resource servers not using an OAuth HTTP
              authentication scheme (see <xref target="authz_header"></xref>)
              should take care to use
              Cache-Control headers to minimize the risk that authenticated
              content is not protected. Such clients should send a
              Cache&nbhy;Control header containing the "no-store" option <xref
              target="RFC2616"></xref>. Resource server success (2XX status)
              responses to these requests should contain a Cache-Control
              header with the "private" option <xref
              target="RFC2616"></xref>.</t>

              <t>Reducing scope (see <xref target="limit_scope"></xref>) and
              expiry time (<xref target="short_exp_time"></xref>) for access
              tokens can be used to reduce the damage in case of leaks.</t>
            </list></t>
          -->
        </section>

        <section title="Threat: Token Leakage via Log Files and HTTP Referrers">
          <t>
            アクセストークンがURIクエリーパラメータとして送られる場合, トークンがログファイルやHTTPリファラーなどを通じて漏洩する可能性がある.
          </t>
          <!--
          <t>If access tokens are sent via URI query parameters, such tokens
          may leak to log files and the HTTP "referer".</t>
          -->

          <t>
            対抗策:
          </t>
          <!--
          <t>Countermeasures:</t>
          -->

          <t>
            <list style="symbols">
              <t>
                URI リクエストパラメーターの代わりに Authorization ヘッダーや POST パラメーターを使う.
                (<xref target="authz_header"></xref>)
              </t>

              <t>
                ログ設定を適切に行う.
              </t>

              <t>
                ログファイルへのアクセスを適切にコントロールする.
                (<xref target="std_sys"></xref>)
              </t>

              <t>
                漏洩したトークンの利用を防止するため, 認証済リクエストを強制することも可能である.
                (<xref target="authn_requests"></xref>)
              </t>

              <t>
                scopeや有効期間を制限することで, 漏洩リスクを軽減する.
                one-timeトークンを利用するのもよい.
                (<xref target="limit_scope"></xref>, <xref target="short_exp_time"></xref>, <xref target="one_time_usage"></xref>)
              </t>
            </list>
          </t>
          <!--
          <t><list style="symbols">
              <t>Use Authorization headers or POST parameters instead of URI
              request parameters (see <xref target="authz_header"></xref>).</t>

              <t>Set logging configuration appropriately.</t>

              <t>Prevent unauthorized persons from access to system log files
              (see <xref target="std_sys"></xref>).</t>

              <t>Abuse of leaked access tokens can be prevented by enforcing
              authenticated requests
              (see <xref target="authn_requests"></xref>).</t>

              <t>The impact of token leakage may be reduced by limiting scope
              (see <xref target="limit_scope"></xref>) and duration (see <xref
              target="short_exp_time"></xref>) and by enforcing one-time token
              usage (see <xref target="one_time_usage"></xref>).</t>
            </list></t>
          -->
        </section>
      </section>
    </section>

    <section anchor="security_considerations" title="Security Considerations">
      <t>
        本セクションでは <xref target="threat_model"/> で述べた脅威を軽減するために推奨する対抗策について述べる.
      </t>
      <!--
      <t>This section describes the countermeasures as recommended to mitigate
      the threats described in <xref target="threat_model"/>.</t>
      -->
      <section title="General">
        <t>
          本セクションでは, すべてのOAuthコンポーネント (クライアント, リソースサーバー, トークンサーバーおよびユーザーエージェント) に対し, 一般に適用可能な対策について考慮する.
        </t>
        <!--
        <t>This section covers considerations that apply generally
        across all OAuth components (client, resource server, token server,
        and user agents).</t>
        -->
        <section anchor="conf_requests"
                 title="Ensure Confidentiality of Requests">
          <t>
            これはクライアントから認可サーバーまたはリソースサーバーへ送信されるすべてのリクエスト対し適用可能である.
            OAuthはリクエストの完全性検証のための方式を提供するが, リクエストの秘匿性を保つための方式は提供しない.
            さらなる予防措置を行わない限り, 盗聴者はリクエストの中身にフルアクセスし, シークレットやトークンなどのリクエストの中身を用いて遮断やリプレイアタックを開始することが可能となる.
          </t>
          <!--
          <t>This is applicable to all requests sent from the client to the
          authorization server or resource server. While OAuth provides a
          mechanism for verifying the integrity of requests, it provides no
          guarantee of request confidentiality. Unless further precautions are
          taken, eavesdroppers will have full access to request content and
          may be able to mount interception or replay attacks by using the
          contents of requests, e.g., secrets or tokens.</t>
          -->

          <t>
            TLS <xref target="RFC5246"></xref> のようなトランスポート層でのセキュリティ機構を用いることによって攻撃を軽減することが可能である.
            IPsec VPN <xref target="RFC4301"></xref> のような仮想プライベートネットワーク (VPN) も同様に考慮に値する.
            (訳注: 「transport-layer mechanisms such as TLS」は, 文脈から「transport-layer "security" mechanisms such as TLS」と見なした. )
          </t>
          <!--
          <t>Attacks can be mitigated by using transport-layer mechanisms such
          as TLS <xref target="RFC5246"></xref>. A virtual private network
          (VPN), e.g., based on IPsec VPNs <xref target="RFC4301"></xref>, may
          be considered as well.</t>
          -->

          <t>
            注: 当文書では各々のプロトコルエンティティ間のコネクションがend-to-endのTLSで保護されていることを想定している.
            データセンターの境界などのようにTLSをオフロードすることによってこの想定から外れているデプロイは, これによって引き起こされる新たな (主に内部者による) 脅威に対処するために, この脅威モデルを改良しなければならない.
          </t>
          <!--
          <t>Note: This document assumes end-to-end TLS protected connections
          between the respective protocol entities. Deployments deviating from
          this assumption by offloading TLS in between (e.g., on the data
          center edge) must refine this threat model in order to account for
          the additional (mainly insider) threat this may cause.</t>
          -->

          <t>
            これは以下の脅威に対する対抗策である:
          </t>
          <!--
          <t>This is a countermeasure against the following threats:</t>
          -->

          <t>
            <list style="symbols">
              <t>
                トークンエンドポイントやリソースサーバーのエンドポイントとの通信路上で得られたアクセストークンのリプレイ
              </t>

              <t>
                トークンエンドポイントとの通信路上で得られたリフレッシュトークンのリプレイ
              </t>

              <t>
                トークンエンドポイントとの通信路上 (もしくはリダイレクト経路上) で得られた認可コードのリプレイ
                (訳注: 原文末尾の「(redirect?)」はクライアントのリダイレクトエンドポイント (redirection endpoint) との通信路上を示していると解釈)
              </t>

              <t>
                ユーザーパスワードとクライアントシークレットのリプレイ
              </t>
            </list>
            (訳注: アクセストークンと認可コードは, 認可エンドポイントとの通信路上も流れるが, 上記で触れらていないのは記述の漏れの可能性あり)
          </t>
          <!--
          <t><list style="symbols">
              <t>Replay of access tokens obtained on the token's endpoint or
              the resource server's endpoint</t>

              <t>Replay of refresh tokens obtained on the token's endpoint</t>

              <t>Replay of authorization "codes" obtained on the token's endpoint
              (redirect?)</t>

              <t>Replay of user passwords and client secrets</t>
            </list></t>
          -->

        </section>

        <section anchor="server_authn" title="Utilize Server Authentication">
          <t>
            HTTPSサーバー認証や類似の手段によってサーバーのアイデンティティを認証することが可能である.
            その目的は, 接続の確立の際にサーバーの完全修飾ドメイン名とサーバーから提示された公開鍵とを確実に結びつけることである.
            (<xref target="RFC2818"></xref> 参照)
          </t>
          <!--
          <t>HTTPS server authentication or similar means can be used to
          authenticate the identity of a server. The goal is to reliably bind
          the fully qualified domain name of the server to the public key
          presented by the server during connection establishment (see <xref
          target="RFC2818"></xref>).</t>
          -->

          <t>
            クライアントはサーバーとそのドメイン名の結びつきを検証すべきである.
            その結びつきの証明に失敗した場合, その通信はman-in-the-middle攻撃を受けていると考えられる.
            このセキュリティ手法は, この目的においてクライアントが信頼している認証局 (CA) に依存している.
            クライアントはこれらの信頼するCAを慎重に選択すべきであり, 信頼するCAの証明書を格納するストレージを変更されないように保護すべきである.
          </t>
          <!--
          <t>The client should validate the binding of the server to its
          domain name. If the server fails to prove that binding, the
          communication is considered a man-in-the-middle attack.
          This security measure depends on the certification authorities
          the client trusts for that purpose.
          Clients should carefully select those trusted CAs and protect the
          storage for trusted CA certificates from modifications.</t>
          -->

          <t>これは以下の脅威に対する対抗策である:</t>
          <!--
          <t>This is a countermeasure against the following threats:</t>
          -->

          <t>
            <list style="symbols">
              <t>なりすまし (Spoofing)</t>

              <t>通信への不正介在 (Proxying)</t>

              <t>偽のサーバーによるフィッシング</t>
            </list>
          </t>
          <!--
          <t><list style="symbols">
              <t>Spoofing</t>

              <t>Proxying</t>

              <t>Phishing by counterfeit servers</t>
            </list></t>
          -->

        </section>

        <section anchor="informed"
                 title="Always Keep the Resource Owner Informed">
          <t>
            リソースオーナーへの透明性は, OAuthプロトコルの鍵となる要素である.
            ユーザーは常に認可処理の指令者であるべきであり, 判断に必要な情報を得られるべきである.
            さらにいえばユーザーの関与はよりよいセキュリティ対抗策である.
            ユーザーは恐らくある種の攻撃に対して, 認可サーバーよりも正しく認識することができる.
            認可プロセス時, 認可プロセス後, そしてユーザーが情報を得たいと思った時のいずれも, 下記のような手法を用いて情報の提示と交換を行うことができる:
          </t>
          <!--
          <t>Transparency to the resource owner is a key element of the OAuth
          protocol. The user should always be in control of the authorization
          processes and get the necessary information to make informed
          decisions. Moreover, user involvement is a further security
          countermeasure. The user can probably recognize certain kinds of
          attacks better than the authorization server. Information can be
          presented/exchanged during the authorization process, after the
          authorization process, and every time the user wishes to get
          informed by using techniques such as:</t>
          -->

          <t>
            <list style="symbols">
              <t>
                ユーザ同意のフォーム.
              </t>

              <t>
                通知メッセージ (例えば, Eメール, SMS, &hellip;).
                通知はフィッシング攻撃の経路にもなりうることに注意.
                通知メッセージは, 攻撃者によく似たフィッシングメッセージを送信されないよう, 考慮すべきである.
              </t>

              <t>
                アクティビティ/イベントログ.
              </t>

              <t>
                ユーザーが自身でセキュリティ対策を行えるようなアプリケーションあるいはポータル.
              </t>
            </list>
          </t>
          <!--
          <t><list style="symbols">
              <t>User consent forms.</t>

              <t>Notification messages (e.g., email, SMS, &hellip;). Note that
              notifications can be a phishing vector. Messages should be such
              that look-alike phishing messages cannot be derived from
              them.</t>

              <t>Activity/event logs.</t>

              <t>User self-care applications or portals.</t>
            </list></t>
          -->

        </section>

        <section title="Credentials">
          <t>
            当セクションでは未認可のアクセスや悪用からあらゆる種類のクレデンシャルを保護するための対抗策について述べる.
            クレデンシャルは, あらゆる種類のトークン (リフレッシュトークンやアクセストークン) や認可コード, あるいはクライアントシークレットやユーザーパスワードのような, 長寿命のシークレットである.
          </t>
          <!--
          <t>This section describes countermeasures used to protect all kinds
          of credentials from unauthorized access and abuse. Credentials are
          long-term secrets, such as client secrets and user passwords as well
          as all kinds of tokens (refresh and access tokens) or
          authorization "codes".</t>
          -->

          <section anchor="cred_storage_prot"
                   title="Enforce Credential Storage Protection Best Practices">
            <t>
              管理者はクレデンシャルのストレージ保護に関する業界のベストプラクティスを採用すべきである
              (例えば, <xref target="OWASP"></xref> 参照).
              このようなプラクティスは以下のサブセクションの事項に限定されるものではない.
            </t>
            <!--
            <t>Administrators should undertake industry best practices to
            protect the storage of credentials (for example, see <xref
            target="OWASP"></xref>). Such practices may include but are not
            limited to the following sub-sections.</t>
            -->

            <section anchor="std_sys"
                     title="Enforce Standard System Security Means">
              <t>
                攻撃者がセンシティブな設定ファイルやデータベースにアクセスできないように, サーバーシステムはロックダウン (権限によりアクセス制限) されていることがある.
              </t>
              <!--
              <t>A server system may be locked down so that no attacker may
              get access to sensitive configuration files and databases.</t>
              -->
            </section>

            <section anchor="std_sql"
                     title="Enforce Standard SQL Injection Countermeasures">
              <t>
                クライアント識別子やその他の認証コンポーネントをSQLデータベースに対し問い合わせたり比較する場合, 受け取ったパラメータを送信する前に検証しなければインジェクション攻撃を受ける可能性がある.
              </t>
              <!--
              <t>If a client identifier or other authentication component is
              queried or compared against a SQL database, it may become
              possible for an injection attack to occur if parameters received
              are not validated before submission to the database.</t>
              -->

              <t><list style="symbols">
                  <t>
                    攻撃経路を減らすため, サーバーコードで利用するデータベース特権が最小限になっていることを確認すること.
                  </t>
                  <!--
                  <t>Ensure that server code is using the minimum database
                  privileges possible to reduce the "surface" of possible
                  attacks.</t>
                  -->

                  <t>
                    入力文字を結合した動的なSQLを避けること.
                    可能であれば静的なSQLを使うこと.
                  </t>
                  <!--
                  <t>Avoid dynamic SQL using concatenated input. If possible,
                  use static SQL.</t>
                  -->

                  <t>
                    動的SQLを使う際は, バインド引数によりクエリをパラメータ化すること.
                  </t>
                  <!--
                  <t>When using dynamic SQL, parameterize queries using bind
                  arguments. Bind arguments eliminate the possibility of SQL
                  injections.</t>
                  -->

                  <t>
                    入力はフィルタリングとサニタイジングを行うこと.
                    例えば, 識別子が既知の書式の時, 提供された値が識別子の構文にマッチしているかを確認すること.
                  </t>
                  <!--
                  <t>Filter and sanitize the input. For example, if an
                  identifier has a known format, ensure that the supplied
                  value matches the identifier syntax rules.</t>
                  -->
                </list></t>
            </section>

            <section anchor="noclear"
                     title="No Cleartext Storage of Credentials">
              <t>
                認可サーバーはクリアテキストでクレデンシャルを格納すべきではない.
                典型的なアプローチは代わりにハッシュを格納するか, クレデンシャルを暗号化することである.
                (ユーザーパスワードであるため) クレデンシャルが十分なエントロピーレベルを持っていない場合, オフライン辞書攻撃を困難にするためのソルトを追加することによってストレージが強固になる.
              </t>
              <!--
              <t>The authorization server should not store credentials in
              clear text. Typical approaches are to store hashes instead or to
              encrypt credentials. If the credential lacks a reasonable
              entropy level (because it is a user password), an additional salt
              will harden the storage to make offline dictionary attacks more
              difficult.</t>
              -->

              <t>
                注: いくつかの認証プロトコルは, 認可サーバがクリアテキストのシークレットにアクセスできる必要がある.
                サーバがハッシュにしかアクセスできない場合, これらのプロトコルを実装することができない.
                このようなケースの場合, クレデンシャルを強固に暗号化するべきである.
              </t>
              <!--
              <t>Note: Some authentication protocols require the authorization
              server to have access to the secret in the clear. Those
              protocols cannot be implemented if the server only has access to
              hashes. Credentials should be strongly encrypted in those
              cases.</t>
              -->
            </section>

            <section title="Encryption of Credentials">
              <t>
                クライアントアプリケーションがクライアントクレデンシャルを安全に永続化していない場合, 攻撃者による取得のターゲットとなりやすい.
                キーストアやデータベースのような暗号化永続機構を用いてクライアントクレデンシャルを格納すること.
                クライアントクレデンシャルを直接クライアントコードに記述するとスキャニングに対し脆弱になる.
                またクライアントクレデンシャルの変更の管理が困難にもなる.
              </t>
              <!--
              <t>For client applications, insecurely persisted client
              credentials are easy targets for attackers to obtain. Store
              client credentials using an encrypted persistence mechanism such
              as a keystore or database. Note that compiling client
              credentials directly into client code makes client applications
              vulnerable to scanning as well as difficult to administer should
              client credentials change over time.</t>
              -->
            </section>

            <section title="Use of Asymmetric Cryptography">
              <t>
                非対称暗号を用いれば, 認可サーバでクレデンシャル管理を行う必要はなくなる.
              </t>
              <!--
              <t>Usage of asymmetric cryptography will free the authorization
              server of the obligation to manage credentials.</t>
              -->
            </section>
          </section>

          <section anchor="online_secrets" title="Online Attacks on Secrets">
            <section anchor="pwd_policy"
                     title="Utilize Secure Password Policy">
              <t>
                オンラインパスワード攻撃を困難にすることに繋がるユーザーパスワードのエントロピー増加のため, 認可サーバーは複雑なユーザーパスワードポリシーを強制することもある.
                複雑にしすぎた場合, ユーザーはパスワードを再利用したり, 紙にメモしたり, 安全でない方法で格納したりする可能性があることに注意すること.
              </t>
              <!--
              <t>The authorization server may decide to enforce a complex user
              password policy in order to increase the user passwords' entropy
              to hinder online password attacks. Note that too much complexity
              can increase the likelihood that users re-use passwords or write
              them down, or otherwise store them insecurely.</t>
              -->
            </section>

            <section anchor="high_entropy"
                     title="Use High Entropy for Secrets">
              <t>
                人間によって利用されるのではないシークレット (例: クライアントシークレットやトークンハンドル) を生成するとき, 推測攻撃のリスクを軽減するために, 認可サーバーは合理的なレベルのエントロピーを含むように生成すべきである.
                認可サーバーは, 128ビット以上の暗号論的に強固な乱数または擬似乱数シーケンスからトークンの値を生成するべきである.
                (本ドキュメント執筆時点のベストプラクティスとして <xref target="RFC4086"></xref> を参照)
              </t>
              <!--
              <t>When creating secrets not intended for usage by human users
              (e.g., client secrets or token handles), the authorization server
              should include a reasonable level of entropy in order to
              mitigate the risk of guessing attacks. The token value should be
              &gt;=128 bits long and constructed from a cryptographically
              strong random or pseudo-random number sequence (see <xref
              target="RFC4086"></xref> for best current practice) generated by
              the authorization server.</t>
              -->
            </section>

            <section anchor="lock_accounts" title="Lock Accounts">
              <t>
                ある一定の回数試行に失敗した場合, そのアカウントをロックすることにより, パスワードに対するオンライン攻撃を軽減することができる.
              </t>
              <!--
              <t>Online attacks on passwords can be mitigated by locking the
              respective accounts after a certain number of failed
              attempts.</t>
              -->

              <t>
                注: この手法は正規のサービスユーザーのロックダウンに悪用される可能がある.
              </t>
              <!--
              <t>Note: This measure can be abused to lock down legitimate
              service users.</t>
              -->
            </section>

            <section anchor="tar_pit" title="Use Tar Pit">
              <t>
                ユーザー名/パスワードによる認証の試行失敗に対して, 認可サーバーはそのアカウントをロックしたり, ある一定の時間, レスポンスを遅延させることがある.
                この時間は, 試行失敗の回数に応じて, 増加することもある.
                この目的は, あるユーザー名に対する攻撃者の試行をスローダウンさせることにある.
              </t>
              <!--
              <t>The authorization server may react on failed attempts to
              authenticate by username/password by temporarily locking the
              respective account and delaying the response for a certain
              duration. This duration may increase with the number of failed
              attempts. The objective is to slow the attacker's attempts on a
              certain username down.</t>
              -->

              <t>
                注: これは認可サーバーのより複雑でステートフルな設計が必要となるかもしれない.
              </t>
              <!--
              <t>Note: This may require a more complex and stateful design of
              the authorization server.</t>
              -->
            </section>

            <section anchor="captchas" title="Use CAPTCHAs">
              <t>
                人間の対話が必要になることにより, このアイデアはプログラムが大規模な数のパスワードの自動チェックを行うことを防ぐ.
              </t>
              <!--
              <t>The idea is to prevent programs from automatically checking
              a huge number of passwords, by requiring human interaction.</t>
              -->

              <t>
                注: これは, ユーザーエクスペリエンスにネガティブなインパクトを与える.
              </t>
              <!--
              <t>Note: This has a negative impact on user experience.</t>
              -->
            </section>
          </section>
        </section>

        <section title="Tokens (Access, Refresh, Code)">
          <section anchor="limit_scope" title="Limit Token Scope">
            <t>
              認可サーバーはトークンに関連付けられたスコープの縮小または制限を決定することもある.
              この決定の基準は当文書のスコープ外である.
              以下は例である:
            </t>
            <!--
            <t>The authorization server may decide to reduce or limit the
            scope associated with a token. The basis of this decision is out
            of scope; examples are:</t>
            -->

            <t>
              <list style="symbols">
                <t>
                  クライアント固有のポリシー.
                  例えば, パブリッククライアントにはより小さな権限のトークンのみ発行するなど.
                </t>

                <t>
                  サーバー固有のポリシー.
                  例えば, とてもセンシティブなサービスなど.
                </t>

                <t>
                  リソースオーナー固有の設定.
                </t>

                <t>
                  または, これらのポリシーや設定の組み合わせ.
                </t>
              </list>
              認可サーバーはグラントタイプに応じて, 異なるスコープを許可することもある.
              例えば, エンドユーザーと認可サーバーが直接対話することで得た認可 (つまり認可コードグラントタイプ) は, クライアントが「ユーザー名」/「パスワード」を認可サーバーに直接送信することで得た認可 (つまりリソースオーナーパスワードクレンデンシャルグラントタイプ) よりも信頼できるとみなすこともある.
              この手法は以下の脅威の影響を減らすことができる:
            </t>
            <!--
            <t><list style="symbols">
                <t>a client-specific policy, e.g., issue only less powerful
                tokens to public clients,</t>

                <t>a service-specific policy, e.g., it is a very sensitive
                service,</t>

                <t>a resource-owner-specific setting, or</t>

                <t>combinations of such policies and preferences.</t>
              </list>The authorization server may allow different scopes
            dependent on the grant type. For example, end-user authorization
            via direct interaction with the end user (authorization "code")
            might be considered more reliable than direct authorization via
            grant type "username"/"password". This means will reduce the
            impact of the following threats:</t>
            -->

            <t><list style="symbols">
                <t>
                  トークン漏洩
                </t>

                <t>
                  悪意のあるソフトウェアへのトークン発行
                </t>

                <t>
                  リソースオーナークレデンシャルフローで意図していない強い権限のトークンの発行
                </t>
              </list>
            </t>
            <!--
            <t><list style="symbols">
                <t>token leakage</t>

                <t>token issuance to malicious software</t>

                <t>unintended issuance of powerful tokens with resource
                owner credentials flow</t>
              </list></t>
            -->
          </section>

          <section anchor="exp_time" title="Determine Expiration Time">
            <t>
              トークンは一般に適切な期間の経過後, 有効期限切れとなるべきである.
              これにより, (署名のような) 他のセキュリティ手法の補完や強化を行うことができ, あらゆる種類のトークン漏洩の影響を減らすことができる.
              トークン漏洩のリスクに応じて, (例えば決済トランザクションに対しては) 数分で有効期限切れとなり, (例えば連絡先情報への読み取りアクセスに対しては) 何時間も有効のままとなる.
            </t>
            <!--
            <t>Tokens should generally expire after a reasonable duration.
            This complements and strengthens other security measures (such as
            signatures) and reduces the impact of all kinds of token leaks.
            Depending on the risk associated with token leakage, tokens may
            expire after a few minutes (e.g., for payment transactions) or stay
            valid for hours (e.g., read access to contacts).</t>
            -->

            <t>
              有効期間は下記のような様々な要因により決定される:
            </t>
            <!--
            <t>The expiration time is determined by several factors,
            including:</t>
            -->

            <t>
              <list style="symbols">
                <t>
                  トークン漏洩のリスクの大きさ
                </t>

                <t>
                  基本的なアクセスを許可する期間
                </t>

                <t>
                  アクセス許可の変更が有効になるまでの期間
                  (訳注: assertionベースのトークンを用いた場合など, ユーザーが認可サーバー上でアクセス無効化を行ってもクライアントの持つアクセストークンが即座に無効化されない場合がある)
                </t>

                <t>
                  攻撃者が有効なトークンを推測または生成するまでの所要時間
                </t>
              </list>
            </t>
            <!--
            <t><list style="symbols">
                <t>risk associated with token leakage,</t>

                <t>duration of the underlying access grant,</t>

                <t>duration until the modification of an access grant should
                take effect, and</t>

                <t>time required for an attacker to guess or produce a valid
                token.</t>
              </list></t>
            -->
          </section>

          <section anchor="short_exp_time" title="Use Short Expiration Time">
            <t>
              短い有効期間のトークンは以下の脅威に対する対策となる:
            </t>
            <!--
            <t>A short expiration time for tokens is a means of protection
            against the following threats:</t>
            -->

            <t>
              <list style="symbols">
                <t>
                  リプレイ
                </t>

                <t>
                  トークン漏洩 (短い有効期間は影響を減らす)
                </t>

                <t>
                  オンライン推測 (短い有効期間は成功の可能性を減らす)
                </t>
              </list>
              注: トークンの有効期間を短くする場合, 認可サーバーとリソースサーバー間のより正確な時刻同期が要求される.
              さらにいえば, 短い有効期間はより多くの (アクセストークンの) トークンリフレッシュを必要とするかもしれないし, エンドユーザによる (認可コードとリフレッシュトークンの) 認可処理の繰り返しに繋がるかもしれない.
            </t>
            <!--
            <t><list style="symbols">
                <t>replay</t>

                <t>token leak (a short expiration time will reduce impact)</t>

                <t>online guessing (a short expiration time will reduce the
                likelihood of success)</t>
              </list>Note: Short token duration requires more precise clock
            synchronization between the authorization server and resource
            server. Furthermore, shorter duration may require more token
            refreshes (access token) or repeated end-user authorization
            processes (authorization "code" and refresh token).</t>
            -->
          </section>

          <section anchor="one_time_usage"
                   title="Limit Number of Usages or One-Time Usage">

            <t>
              認可サーバーはトークンの利用回数を制限してもよい.
              これにより以下の脅威を軽減することができる:
            </t>
            <!--
            <t>The authorization server may restrict the number of requests or
            operations that can be performed with a certain token. This
            mechanism can be used to mitigate the following threats:</t>
            -->

            <t>
              <list style="symbols">
                <t>
                  トークンのリプレイ
                </t>

                <t>
                  推測
                </t>
              </list>
              例えば, 認可サーバーがある認可コードの交換の試行を複数回観測した場合, 現在のリクエストだけでなく, その認可コードに関連づいた全てのアクセストークンを無効化することもありうる.
            </t>
            <!--
            <t><list style="symbols">
                <t>replay of tokens</t>

                <t>guessing</t>
              </list>For example, if an authorization server observes more
            than one attempt to redeem an authorization "code", the
            authorization server may want to revoke all access tokens granted
            based on the authorization "code" as well as reject the current
            request.</t>
            -->

            <t>
              認可コードと同様に, アクセストークンも操作回数に制限があってもよい.
              これは, クライアントアプリケーションを再認証し, 新たなアクセストークンを取得するためにリフレッシュトークンを使用することを強制するか, ユーザーも関与させてアクセストークンの再認可をクライアントに強制することになる.
            </t>
            <!--
            <t>As with the authorization "code", access tokens may also have a
            limited number of operations. This either forces client
            applications to re-authenticate and use a refresh token to
            obtain a fresh access token, or forces the client to
            re-authorize the access token by involving the user.</t>
            -->
          </section>

          <section anchor="bind_token_rs"
                   title="Bind Tokens to a Particular Resource Server (Audience)">
            <t>
              マルチサービス環境にある認可サーバーは, 送信先として意図しているサーバーを明示的にトークン内に指定するなど, 異なるリソースサーバーに対して異なる内容のトークンを発行してもよい.
              SAMLアサーション (<xref target="OASIS.saml-core-2.0-os"></xref> 参照) は, この目的のために Audience 要素を用いている.
              この対抗策は以下の状況に対して使用される:
            </t>
            <!--
            <t>Authorization servers in multi-service environments may
            consider issuing tokens with different content to different
            resource servers and to explicitly indicate in the token the
            target server to which a token is intended to be sent.
            SAML assertions
            (see <xref target="OASIS.saml-core-2.0-os"></xref>) use the
            Audience element for this purpose. This countermeasure can be used
            in the following situations:</t>
            -->

            <t>
              <list style="symbols">
                <t>
                  このトークンは一つのリソースサーバーにのみ適用できるため, リプレイ試行の成功の影響を減らす.
                </t>

                <t>
                  このトークンは指定されたリソースサーバーやクライアントでのみ利用できるため, 悪意のあるリソースサーバーやクライアントが自身宛のトークンを他のサーバーに対して悪用することを防ぐ.
                  それを行っても他のサーバによって拒絶される.
                  (訳注: 具体的な被害例はこちらを http://oauth.jp/oauth-20-implicit-flow)
                </t>

                <t>
                  偽のリソースサーバーに対する有効なトークンの漏洩の影響を減らす.
                </t>
              </list></t>
            <!--
            <t><list style="symbols">
                <t>It reduces the impact of a successful replay attempt, since
                the token is applicable to a single resource server only.</t>

                <t>It prevents abuse of a token by a rogue resource server or
                client, since the token can only be used on that server. It is
                rejected by other servers.</t>

                <t>It reduces the impact of leakage of a valid token to a
                counterfeit resource server.</t>
              </list></t>
            -->
          </section>

          <section anchor="endpoint_audience"
                   title="Use Endpoint Address as Token Audience">
            <t>
              トークン取得時にaudienceとしてエンドポイントURLを指定することで, リソースサーバーを指定することもできる.
              このトークンはリソースサーバー自身のエンドポイントURLを含むため, リソースサーバーは他のリソースサーバーからの不正アクセスを検知することができる.
              (訳注: 複数のリソースサーバーが1つの認可サーバーに認可を委ねており, かつリソースサーバー同士の間に信頼関係が構築できないケースに有効)
            </t>
            <!--
            <t>This may be used to indicate to a resource server which
            endpoint URL has been used to obtain the token. This measure will
            allow the detection of requests from a counterfeit resource server,
            since such a token will contain the endpoint URL of that
            server.</t>
            -->

          </section>

          <section anchor="audience_token_scope"
                   title="Use Explicitly Defined Scopes for Audience and Tokens">
            <t>
              実装者は, 各scopeに特定のリソースサーバーに対するアクセス権限を表現させ, 各トークンが明示的にそれらのscopeを持つように設計することもできる.
              (訳注: 暗黙的なdefault scopeを許可しないということ)
              このアプローチは, リソースサーバーやクライアントが想定外の目的でトークンを利用するという攻撃を軽減することができる.
            </t>
            <!--
            <t>Deployments may consider only using tokens with explicitly
            defined scopes, where every scope is associated with a particular
            resource server. This approach can be used to mitigate attacks
            where a resource server or client uses a token for a different
            purpose than the one intended.</t>
            -->
          </section>

          <section anchor="bind_token_client_id"
                   title="Bind Token to Client id">
            <t>
              認可サーバーはトークンを特定のクライアント識別子に結びつけることもできる.
              この識別子はトークン付きの全てのリクエストに対し検証されるべきである.
              この手法は以下の目的で利用できる:
            </t>
            <!--
            <t>An authorization server may bind a token to a certain client
            identifier. This identifier should be validated for every request
            with that token. This technique can be used to</t>
            -->

            <t>
              <list style="symbols">
                <t>
                  トークン漏洩の検出
                </t>

                <t>
                  トークン悪用の防止
                </t>
              </list>
              注: クライアント識別子の検証は, ターゲットサーバーにクライアントの識別子を認証することを要求することもある.
              この認証は, (例えば, 認可サーバー上に事前登録されたクライアント識別子とシークレットのような) トークンとは独立して管理されたシークレットを利用するか,
              あるいは (例えば, 暗号化されたトークンの中身の一部として) トークン自身と共に送ることで可能となる.
            </t>
            <!--
            <t><list style="symbols">
                <t>detect token leakage and</t>

                <t>prevent token abuse.</t>
              </list>Note: Validating the client identifier may require the
            target server to authenticate the client's identifier. This
            authentication can be based on secrets managed independently of the
            token (e.g., pre-registered client id/secret on authorization
            server) or sent with the token itself (e.g., as part of the
            encrypted token content).</t>
            -->
          </section>

          <section anchor="signed_tokens" title="Sign Self-Contained Tokens">
            <t>
              改竄や偽のトークンの生成を検出するために, self-containedトークンは (例えば, ハッシュベースメッセージ認証コードやデジタル署名を用いて) 署名されるべきである.
            </t>
            <!--
            <t>Self-contained tokens should be signed in order to detect any
            attempt to modify or produce faked tokens (e.g., Hash-based Message
            Authentication Code or digital signatures).</t>
            -->
          </section>

          <section anchor="enc_token" title="Encrypt Token Content">
            <t>
              self-containedトークンは, 秘匿性やシステムの内部データを保護するために暗号化されるかもしれない.
              トークンの書式に従い, (例えば共通鍵のような) 鍵がサーバノード間で流通されなければならないかもしれない.
              トークンや暗号化の方法といった流通の方法を定義すべきである.
            </t>
            <!--
            <t>Self-contained tokens may be encrypted for confidentiality
            reasons or to protect system internal data. Depending on token
            format, keys (e.g., symmetric keys) may have to be distributed
            between server nodes. The method of distribution should be defined
            by the token and the encryption used.</t>
            -->
          </section>

          <section anchor="assertion_format" title="Adopt a Standard Assertion Format">
            <t>
              アサーションベースのトークンデザインを実装しようするサービス提供者は, 標準のアサーションフォーマットを採用することを強く推奨する (例えば, SAML <xref target="OASIS.saml-core-2.0-os"></xref>や, JavaScript Object Notation Web Token (JWT) <xref target="OAuth-JWT"></xref>のような).
            </t>
            <!--
            <t>For service providers intending to implement an assertion-based
            token design, it is highly recommended to adopt a standard
            assertion format (such as SAML <xref
            target="OASIS.saml-core-2.0-os"></xref> or the
            JavaScript Object Notation Web Token (JWT) <xref
            target="OAuth-JWT"></xref>).</t>
            -->
          </section>
        </section>

        <section anchor="access_tokens" title="Access Tokens">
          <t>
            アクセストークンを保護するために以下の手法が使われるべきである:
          </t>
          <!--
          <t>The following measures should be used to protect access
          tokens:</t>
          -->

          <t>
            <list style="symbols">
              <t>
                (クライアントアプリケーションからのみアクセス可能な) 一時的なメモリに保持すること.
              </t>

              <t>
                安全なトランスポート (TLS) を用いて安全にトークンを受け渡すこと.
              </t>

              <t>
                クライアントアプリケーションはサードパーティーとトークンを共有しないことを確認すること.
              </t>
            </list></t>
          <!--
          <t><list style="symbols">
              <t>Keep them in transient memory (accessible by the client
              application only).</t>

              <t>Pass tokens securely using secure transport (TLS).</t>

              <t>Ensure that client applications do not share tokens with 3rd
              parties.</t>
            </list></t>
          -->
        </section>
      </section>

      <section title="Authorization Server">
        <t>
          当セクションではOAuth認可サーバのエンドポイントに関する注意点について述べる.
        </t>
        <!--
        <t>This section describes considerations related to the OAuth
        authorization server endpoint.</t>
        -->

        <section title="Authorization &quot;codes&quot;">
          <section anchor="automatic_code_revocation"
                   title="Automatic Revocation of Derived Tokens If Abuse Is Detected">
            <t>
              認可サーバーが (例えば, 認可コードのような) 認可グラント交換リクエストを複数回検知した場合, その認可グラントに関連づいた全てのトークンを無効化することもありうる.
            </t>
            <!--
            <t>If an authorization server observes multiple attempts to redeem
            an authorization grant (e.g., such as an authorization "code"), the
            authorization server may want to revoke all tokens granted based
            on the authorization grant.</t>
            -->
          </section>
        </section>

        <section anchor="refresh_tokens" title="Refresh Tokens">
          <section anchor="restricted_refresh"
                   title="Restricted Issuance of Refresh Tokens">
            <t>
              認可サーバーは, 適切なポリシーに基づいて, リフレッシュトークンを発行しないと決断することもありうる.
              リフレッシュトークンは長期間有効なクレデンシャルのため, 窃取される可能性が高いかもしれない.
              例えば, 認可サーバはこのようなトークンを安全に格納できないと考えられるクライアントに対し, リフレッシュトークンの発行を拒否することもありうる.
            </t>
            <!--
            <t>The authorization server may decide, based on an appropriate
            policy, not to issue refresh tokens. Since refresh tokens are
            long-term credentials, they may be subject to theft.
            For example, if the
            authorization server does not trust a client to securely store
            such tokens, it may refuse to issue such a client a refresh
            token.</t>
            -->
          </section>

          <section anchor="binding_refresh_client_id"
                   title="Binding of Refresh Token to &quot;client_id&quot;">
            <t>
              認可サーバーは全てのリフレッシュトークンについて, 意図している発行先のクライアントの識別子とマッチしているかの確認処理をすべきである.
              認可サーバーは同じ "client_id" がアクセストークンのリフレッシュ要求の全てに存在することをチェックすべきである.
              (例えばコンフィデンシャルクライアントのように) 可能な場合, 認可サーバーは各リクエストにおいてクライアントを認証すべきである.
            </t>
            <!--
            <t>The authorization server should match every refresh token to
            the identifier of the client to whom it was issued. The
            authorization server should check that the same "client_id" is
            present for every request to refresh the access token. If possible
            (e.g., confidential clients), the authorization server should
            authenticate the respective client.</t>
            -->

            <t>
              これはリフレッシュトークンの窃取や漏洩に対する対抗策である.
            </t>
            <!--
            <t>This is a countermeasure against refresh token theft or
            leakage.</t>
            -->

            <t>
              注: このリフレッシュトークンと "client_id" の対応は認可なしに変更されないように保護されるべきである.
            </t>
            <!--
            <t>Note: This binding should be protected from unauthorized
            modifications.</t>
            -->
          </section>

          <section anchor="refresh_replace" title="Refresh Token Rotation">
            <t>
              リフレッシュトークンローテーションは, 異なるアプリケーションやデバイスから同時に同じリフレッシュトークンが利用されることを自動的に検出し阻止することを意図している.
              この事態はクライアントからトークンが盗まれ, それを攻撃者と正当なクライアントの両方が用いた場合に発生する.
              基本的な考えは, 古いリフレッシュトークンを用いたアクセストークン取得の試行を検出するために, 全てのリフレッシュリクエストの度にリフレッシュトークンの値を変更することである.
              認可サーバーは攻撃者と正当なクライアントのどちらがアクセスしようとしているのか判断できないため, 古いリフレッシュトークンを用いたアクセス試行があった場合, 有効なリフレッシュトークンとこれに関連したアクセス認可の両方を無効化する.
            </t>
            <!--
            <t>Refresh token rotation is intended to automatically detect and
            prevent attempts to use the same refresh token in parallel from
            different apps/devices. This happens if a token gets stolen from
            the client and is subsequently used by both the attacker and the
            legitimate client. The basic idea is to change the refresh token
            value with every refresh request in order to detect attempts to
            obtain access tokens using old refresh tokens. Since the
            authorization server cannot determine whether the attacker or the
            legitimate client is trying to access, in case of such an access
            attempt the valid refresh token and the access authorization
            associated with it are both revoked.</t>
            -->

            <t>
              OAuth仕様は, グラントタイプが "refresh_token" のときでも, 認可サーバーが新たなリフレッシュトークンをトークンレスポンスとして返すのを可能とすることでこの方法をサポートしている.
            </t>
            <!--
            <t>The OAuth specification supports this measure in that the
            token's response allows the authorization server to return a new
            refresh token even for requests with grant type
            "refresh_token&ldquo;.</t>
            -->

            <t>
              注: この方法は, 現在有効なリフレッシュトークンの使用状況を確認しなければならないため, クラスター環境では問題を引き起こす可能性がある.
              このような環境では, 他の方法の方がより適切であるかもしれない.
            </t>
            <!--
            <t>Note: This measure may cause problems in clustered environments,
            since usage of the currently valid refresh token must be ensured.
            In such an environment, other measures might be more
            appropriate.</t>
            -->
          </section>

          <section anchor="refresh_revocation" title="Revocation of Refresh Tokens">
            <t>
              認可サーバーは, クライアントまたはエンドユーザーによるリフレッシュトークン無効化の明示的なリクエストを許可してもよい.
              トークンの無効化方法は <xref target="OAuth-REVOCATION"></xref> で仕様化されている.
            </t>
            <!--
            <t>The authorization server may allow clients or end users to
            explicitly request the invalidation of refresh tokens. A mechanism
            to revoke tokens is specified in <xref
            target="OAuth-REVOCATION"></xref>.</t>
            -->

            <t>
              これは以下に対する対抗策となる:
            </t>
            <!--
            <t>This is a countermeasure against:</t>
            -->

            <t><list style="symbols">
                <t>
                  デバイスの盗難
                </t>

                <t>
                  リソースオーナーのなりすまし
                </t>

                <t>
                  信用できなくなったクライアントアプリケーション
                </t>
              </list></t>
            <!--
            <t><list style="symbols">
                <t>device theft,</t>

                <t>impersonation of a resource owner, or</t>

                <t>suspected compromised client applications.</t>
              </list></t>
            -->
          </section>

          <section anchor="device_id" title="Device Identification">
            <t>
              認可サーバーは認証クレデンシャルとデバイス識別子の紐付けを要求してもよい.
              International Mobile Station Equipment Identity <xref target="IMEI"></xref> はこのような識別子の一例である. またOS固有の識別子も存在する.
              特定のデバイスからトークンが窃取されたことを検出するために, 認可サーバーはユーザークレデンシャルの認証時にこのような識別子を含めることができる.
            </t>
            <!--
            <t>The authorization server may require the binding of
            authentication credentials to a device identifier.
            The International Mobile Station Equipment
            Identity
            <xref target="IMEI"></xref> is one example of such an identifier;
            there are also operating system-specific identifiers. The
            authorization server could include such an identifier when
            authenticating user credentials in order to detect token theft
            from a particular device.</t>
            -->

            <t>
              注: いかなる実装においてもデバイス識別子を用いることのプライバシーへの影響の可能性を考慮すべきである.
            </t>
            <!--
            <t>Note: Any implementation should consider potential privacy
            implications of using device identifiers.</t>
            -->
          </section>

          <section anchor="clickjacking_xframe" title="X-FRAME-OPTIONS Header">
            <t>
              X-FRAME-OPTIONS ヘッダー (<xref target="X-Frame-Options"></xref> 参照) をサーバーサイドから指定することによって, iframeでの表示を回避することを最近のブラウザに対しては強制することができる.
              このヘッダーは "DENY" と "SAMEORIGIN" という2種類の値を持つことができ, フレーム表示を一切禁止することと, 異なるオリジンのサイトでは禁止することをそれぞれ意味する.
              "ALLOW-FROM" という値を指定することができるブラウザも存在し, この場合は, iframeでの表示を許可する信頼できるオリジンのリストも併せて指定する.
            </t>
            <!--
            <t>For newer browsers, avoidance of iFrames can be enforced on the
            server side by using the X-FRAME-OPTIONS header (see <xref
            target="X-Frame-Options"></xref>). This header can
            have two values, "DENY" and "SAMEORIGIN", which will block any
            framing or any framing by sites with a different origin,
            respectively. The value "ALLOW-FROM" specifies a list of
            trusted origins that iFrames may originate from.</t>
            -->

            <t>
              これは以下の脅威に対する対抗策である:
            </t>
            <!--
            <t>This is a countermeasure against the following threat:</t>
            -->

            <t>
              <list style="symbols">
                <t>クリックジャッキング攻撃</t>
              </list>
            </t>
            <!--
            <t><list style="symbols">
                <t>Clickjacking attacks</t>
              </list></t>
            -->
          </section>
        </section>

        <section anchor="client_aa"
                 title="Client Authentication and Authorization">
          <t>
            <xref target="sec_features"/> (Security Features) で述べたように, クライアントは以下のような様々な目的で識別, 認証, 認可される.
          </t>
          <!--
          <t>As described in <xref target="sec_features"/> (Security Features),
          clients are identified, authenticated, and authorized for several
          purposes, such as to:</t>
          -->

          <t>
            <list style="symbols">
              <t>
                一連のリクエストが同じクライアントで実行されているか照合する.
              </t>

              <t>
                認可サーバーによってクライアントが認識されていることをユーザーに示す.
              </t>

              <t>
                認可サーバーやリソースサーバー上の機能へのクライアントのアクセスを認可する.
              </t>

              <t>
                分析や統計のためにクライアント識別子をログファイルに記録する.
              </t>
            </list>
            クライアントタイプ毎に機能や特性が異なるため, 上記の目的を達成する方法も複数ある.
            これらの方法について当セクションで述べる.
            認可サーバー提供者はセキュリティポリシーとクライアントのデプロイについて注意し, それに従って適切に取り扱うべきである.
            例えば一つの例として, 全てのクライアントは信頼できず安全ではないとみなして取り扱うといったようなことが挙げられるだろう.
            その対極として, サービス提供者は全てのクライアントのインストールを管理者が個々に有効化することによって, ソフトウェアパッケージのアイデンティティに対する信頼性と, このクライアントがインストールされた環境のセキュリティを確保するといった例が挙げられる.
            これら2つの例の間の中間的なアプローチもいくつも考えられる.
          </t>
          <!--
          <t><list style="symbols">
              <t>Collate requests to the same client,</t>

              <t>Indicate to the user that the client is recognized by the
              authorization server,</t>

              <t>Authorize access of clients to certain features on the
              authorization server or resource server, and</t>

              <t>Log a client identifier to log files for analysis or
              statistics.</t>
            </list>Due to the different capabilities and characteristics of
          the different client types, there are different ways to support
          these objectives, which will be described in this section.
          Authorization server providers should be aware of the security
          policy and deployment of a particular client and adapt its
          treatment accordingly. For example, one approach could be to treat
          all clients as less trustworthy and unsecure. On the other extreme,
          a service provider could activate every client installation
          individually by an administrator and in that way gain confidence
          in the identity of the software package and the security of the
          environment in which the client is installed. There are
          several approaches in between.</t>
          -->

          <section anchor="dont_issue"
                   title="Don't Issue Secrets to Clients with Inappropriate Security Policy">
            <t>
              認可サーバーはシークレットを保護できないクライアント (パブリッククライアント) に対してシークレットを発行すべきではない.
              これはクライアントが強固に認証されたと認可サーバーが取り扱ってしまう可能性を減らす.
            </t>
            <!--
            <t>Authorization servers should not issue secrets to clients that
            cannot protect secrets ("public" clients). This reduces the
            probability of the server treating the client as strongly
            authenticated.</t>
            -->

            <t>
              例えば, あるネイティブアプリケーションの全てのインストールで共有される単一のクライアント識別子とシークレットを生成することは, あまりよくない.
              このようなシナリオでは, アプリケーションマーケットのような配布チャネルを通じて, 開発者からそのアプリケーションを利用する全てのエンドユーザのデバイスに対してシークレットを伝えなければならない.
              アプリケーションのソースコードや関連のリソースバンドルに埋め込まれたシークレットは, リバースエンジニアリングに対しては無力である.
              次に, このようなシークレットを無効化すると, そのアプリケーションの全てのインストールが即座に動作しなくなってしまうため, 無効化することができない.
              さらに, 認可サーバーはクライアント識別子を実際には信用できないため, そのクライアントの信頼性をエンドユーザに示すことは危険だろう.
            </t>
            <!--
            <t>For example, it is of limited benefit to create a single client
            id and secret that are shared by all installations of a native
            application. Such a scenario requires that this secret must be
            transmitted from the developer via the respective distribution
            channel, e.g., an application market, to all installations of the
            application on end-user devices. A secret, burned into the source
            code of the application or an associated resource bundle, is not
            protected from reverse engineering. Secondly, such secrets cannot
            be revoked, since this would immediately put all installations out
            of work. Moreover, since the authorization server cannot really
            trust the client's identifier, it would be dangerous to indicate
            to end users the trustworthiness of the client.</t>
            -->

            <t>
              以下のセクションで述べるように, 妥当なセキュリティレベルを達成する他の方法がある:
            </t>
            <!--
            <t>There are other ways to achieve a reasonable security level, as
            described in the following sections.</t>
            -->
          </section>

          <section anchor="forced_user_consent"
                   title="Require User Consent for Public Clients without Secret">
            <t>
              認可サーバーはパブリッククライアントに対し自動認可を許すべきではない.
              認可サーバーは個々のクライアント識別子を発行するかもしれないが, 全ての認可処理はエンドユーザーによる承認を必要とすべきである.
              シークレットなしのクライアントは, 以下の脅威に対する対抗策である:
            </t>
            <!--
            <t>Authorization servers should not allow automatic authorization
            for public clients. The authorization server may issue an
            individual client id but should require that all authorizations
            are approved by the end user. For clients without secrets, this is
            a countermeasure against the following threat:</t>
            -->

            <t>
              <list style="symbols">
                <t>
                  パブリッククライアントアプリケーションのなりすまし.
                </t>
              </list></t>
            <!--
            <t><list style="symbols">
                <t>Impersonation of public client applications.</t>
              </list></t>
            -->
          </section>

          <section anchor="client_id_redirect"
                   title="Issue a &quot;client_id&quot; Only in Combination with &quot;redirect_uri&quot;">
            <t>
              認可サーバーは "client_id" の発行と共に, その "client_id" に対し事前設定されたクライアント個別の "redirect_uri" を関連付けるかもしれない.
              そして, 異なるリダイレクトURIを持つ認可リクエストを受けた場合は自動的に拒否する.
              もしくは, 認可サーバーは認可リクエストにどのようなリダイレクトURIが設定されていたとしてもそれを無視し, 代わりに既知の事前設定されたリダイレクトURIに対して常にリダイレクトすべきである.
              これはシークレットを持たないクライアントにおける以下の脅威に対する対抗策である:
            </t>
            <!--
            <t>The authorization server may issue a "client_id" and bind the
            "client_id"
            to a certain pre-configured "redirect_uri". Any authorization
            request with another redirect URI is refused automatically.
            Alternatively, the authorization server should not accept any
            dynamic redirect URI for such a "client_id" and instead should
            always
            redirect to the well-known pre-configured redirect URI. This is
            a countermeasure for clients without secrets against the following
            threats:</t>
            -->

            <t>
              <list style="symbols">
                <t>
                  クロスサイトスクリプティング攻撃
                </t>

                <t>
                  パブリッククライアントアプリケーションのなりすまし
                </t>
              </list></t>
            <!--
            <t><list style="symbols">
                <t>Cross-site scripting attacks</t>

                <t>Impersonation of public client applications</t>
              </list></t>
            -->
          </section>

          <section anchor="depl_specific_secretes"
                   title="Issue Installation-Specific Client Secrets">
            <t>
              認可サーバーは, ある一つのクライアント (つまりソフトウェアパッケージ) について, インストール毎に異なるクライアント識別子とシークレットを発行するかもしれない.
              このようなアプローチは, "public" クライアントを "confidential" クライアントに変える効果があるだろう.
            </t>
            <!--
            <t>An authorization server may issue separate client identifiers
            and corresponding secrets to the different installations of a
            particular client (i.e., software package). The effect of such an
            approach would be to turn otherwise "public" clients back into
            "confidential" clients.</t>
            -->

            <t>
              ウェブアプリケーションにとっては, これは一つの "client_id" とソフトウェアパッケージがインストールされているウェブサイト毎に異なる一つの "client_id" と "client_secret" のペアを作ることを意味するだろう.
              そして, その個々のサイトの提供者はウェブサイトのセットアップの際に, 認可サーバーにクライアント識別子とシークレットを要求することになるだろう.
              これは, そのウェブサイトのリダイレクトURIやウェブサイトURL, その他の有用な属性の検証を可能とするだろう.
              このウェブサイトの提供者はそのサイト上でのクライアントシークレットのセキュリティを確保しなければならない.
            </t>
            <!--
            <t>For web applications, this could mean creating one "client_id"
            and "client_secret" for each web site on which a software package
            is installed. So, the provider of that particular site could
            request a client id and secret from the authorization server
            during the setup of the web site. This would also allow the
            validation of some of the properties of that web site,
            such as redirect URI, web site URL, and whatever else
            proves useful. The web site provider has to ensure the security of
            the client secret on the site.</t>
            -->

            <t>
              ネイティブアプリケーションにとっては, あるアプリケーションの様々なデバイス上における全てのコピーは異なるインストールであるため, より複雑である.
              このシナリオではインストール固有のシークレットとして, 以下のどちらかのパターンで "client_id" と "client_secret" を取得する必要が出てくる:
            </t>
            <!--
            <t>For native applications, things are more complicated because
            every copy of a particular application on any device is a
            different installation. Installation-specific secrets in this
            scenario will require obtaining a "client_id" and "client_secret" either
            </t>
            -->

            <t>
              <list style="numbers">
                <t>
                  アプリケーションマーケットからのダウンロードプロセス中
                </t>

                <t>
                  デバイスへのインストール中
                </t>
              </list>
              いずれのアプローチもクライアント識別子とシークレットを発行するための自動機構が必要となるであろうが, OAuthでは現状その機構を定義していない.
            </t>
            <!--
            <t><list style="numbers">
                <t>during the
                download process from the application market, or</t>

                <t>during installation on the device.</t>
              </list>Either approach will require an automated mechanism for
            issuing client ids and secrets, which is currently not defined by
            OAuth.</t>
            -->

            <t>
              一つ目のアプローチはアプリケーションの真正性に対するある程度の信頼が確保できるが, 二つ目のオプションはクライアントの属性の検証ではなくインストールの真正性のみが確保される.
              しかしこれは少なくとも, 様々なリプレイ攻撃を防止する助けになるだろう.
              さらに, インストール固有のクライアント識別子とシークレットは, 特定のインストールに対する全てのリフレッシュトークンの選択的な無効化を一度で行うことを可能とする.
            </t>
            <!--
            <t>The first approach would allow the achievement of a
            certain level of trust in the authenticity of the application,
            whereas the second option only allows the authentication of the
            installation but not the validation of properties of the client.
            But this would at least help to
            prevent several replay attacks. Moreover, installation-specific
            "client_ids" and secrets allow the selective revocation of all
            refresh tokens of a specific installation at once.</t>
            -->
          </section>

          <section anchor="val_redirect"
                   title="Validate Pre-Registered &quot;redirect_uri&quot;">
            <t>
              認可サーバーは全てのクライアントに "redirect_uri" を登録することを要求すべきであり, その "redirect_uri" は <xref target="RFC6749"></xref> で定義された完全なURIであるべきである.
              この登録の方法については当ドキュメントの対象外である.
              OAuthのコア仕様のとおり, エンドユーザー認可エンドポイントへそれぞれの "client_id" と共に送信されるリダイレクトURIは, 登録されているリダイレクトURIと合致していなければならない.
              それが合致していなかった場合, 認可サーバーはその受信したGETリクエストは攻撃者によって送信されたものとみなし, 拒絶するべきである.
              注: 認可サーバーはこのような認可リクエストのリダイレクトURIにユーザーエージェントをリダイレクトすべきではない.
              事前登録された "redirect_uri" を検証することは, 以下の脅威に対する対抗策となる:
            </t>
            <!--
            <t>An authorization server should require all clients to register
            their "redirect_uri", and the "redirect_uri" should be the full URI as
            defined in <xref target="RFC6749"></xref>. The way that this
            registration is performed is out of scope of this document. As per
            the core spec, every actual redirect URI sent with the
            respective "client_id" to the end-user authorization endpoint must
            match the registered redirect URI. Where it does not match, the
            authorization server should assume that the inbound GET request has
            been sent by an attacker and refuse it. Note: The authorization
            server should not redirect the user agent back to the redirect URI
            of such an authorization request. Validating the
            pre-registered "redirect_uri" is a countermeasure against the
            following threats:</t>
            -->

            <t>
              <list style="symbols">
                <t>
                  偽のウェブサイトへの認可コードの漏洩:
                  これは, エンドユーザーが最初に認可エンドポイントにリダイレクトされてきた際に認可サーバーによって攻撃の試行の検出を可能とする.
                  (<xref target="authz_code_leakage"></xref>)
                </t>

                <t>
                  クライアントのリダイレクトエンドポイントを通じたオープンリダイレクタ攻撃.
                  (<xref target="open_redirector_client"></xref>)
                </t>

                <t>
                  認可サーバーのリダイレクトエンドポイントを通じたオープンリダイレクタフィッシング攻撃.
                  (<xref target="open_redirector"></xref>)
                </t>
              </list>
              この手法の根底にある想定は, 認可コードを取得するには攻撃者がその他のリダイレクトURIを使用する必要が出てくることである.
              実装者は, 攻撃者がこのセキュリティ手法を回避するために被害者のデバイスに対してなりすまし攻撃を行う可能性を検討するかもしれない.
            </t>
            <!--
            <t><list style="symbols">
                <t>Authorization "code" leakage through counterfeit web site:
                allows authorization servers to detect attack attempts after the
                first redirect to an end-user authorization endpoint (<xref
                target="authz_code_leakage"></xref>).</t>

                <t>Open redirector attack via a client redirection endpoint
                (<xref target="open_redirector_client"></xref>).</t>

                <t>Open redirector phishing attack via an authorization server
                redirection endpoint (<xref target="open_redirector"></xref>).
                </t>
              </list> The underlying assumption of this measure is that an
            attacker will need to use another redirect URI in order to get
            access to the authorization "code". Deployments might consider the
            possibility of an attacker using spoofing attacks to a victim's
            device to circumvent this security measure.</t>
            -->

            <t>
              注: クライアントの事前登録は (手動で処理する) デプロイではスケールしないかもしれない.
              または (まだ仕様化されていない) 動的クライアント登録を必要とするかもしれない.
              動的クライアント登録がない場合, 事前登録された "redirect_uri" は開発・設定時のデプロイに紐づけられたクライアントでのみ有効に動作する.
              即時の動的なリソースサーバーのディスカバリーが必要な場合は, この事前登録 "redirect_uri" ではもはや実現可能ではないかもしれない.
            </t>
            <!--
            <t>Note: Pre-registering clients might not scale in some
            deployments (manual process) or require dynamic client
            registration (not specified yet). With the lack of dynamic client
            registration, a pre-registered "redirect_uri" only works for
            clients bound to certain deployments at
            development/configuration time. As
            soon as dynamic resource server discovery is required, the
            pre-registered "redirect_uri" may no longer be feasible.</t>
            -->
          </section>

          <section anchor="client_secret_revocation"
                   title="Revoke Client Secrets">
            <t>
              認可サーバーは漏洩したシークレットの悪用を防止するため, クライアントのシークレットを無効化するかもしれない.
            </t>
            <!--
            <t>An authorization server may revoke a client's secret in order
            to prevent abuse of a revealed secret.</t>
            -->

            <t>
              注: この手段では, 対象のクライアントに発行された認可コードやリフレッシュトークンも即時にすべて無効化するだろう.
              これは対象のネイティブアプリケーションやウェブアプリケーションの複数のデプロイで使用されているクライアント識別子やシークレットに意図しない影響を与えるかもしれない.
            </t>
            <!--
            <t>Note: This measure will immediately invalidate any
            authorization "code" or refresh token issued to the respective
            client. This might unintentionally impact client identifiers
            and secrets used across multiple deployments of a particular
            native or web application.</t>
            -->

            <t>
              これは以下に対する対抗策である
            </t>
            <!--
            <t>This a countermeasure against:</t>
            -->

            <t>
              <list style="symbols">
                <t>
                  プライベートクライアントの漏洩したクライアントシークレットの悪用
                </t>
              </list>
            </t>
            <!--
            <t><list style="symbols">
                <t>Abuse of revealed client secrets for private clients</t>
              </list></t>
            -->
          </section>

          <section anchor="strong_client_authn"
                   title="Use Strong Client Authentication (e.g., client_assertion/client_token)">
            <t>
              クライアントアサーション <xref target="OAuth-ASSERTIONS"></xref> のような代替の認証方式を使用することによって, "client_secret" の流通が不要となる.
              これは, 安全な秘密鍵ストアや認証プロセス中にクライアントアサーションの発行者によって指定されたその他の追加の認証システムの使用が必要となるかもしれない.
            </t>
            <!--
            <t>By using an alternative form of authentication such as client
            assertion <xref target="OAuth-ASSERTIONS"></xref>, the need to
            distribute a "client_secret" is eliminated. This may require
            the use of a secure private key store or other supplemental
            authentication system as specified by the client assertion issuer
            in its authentication process.</t>
            -->
          </section>
        </section>

        <section title="End-User Authorization">
          <t>
            当セクションではエンドユーザーの関与する認可フローに関する注意点について述べる.
          </t>
          <!--
          <t>This section includes considerations for authorization flows
          involving the end user.</t>
          -->

          <section anchor="automatic_processing"
                   title="Automatic Processing of Repeated Authorizations Requires Client Validation">
            <t>
              クライアントがクライアントシークレットによる認証や, または署名された認証アサーション証明書 (<xref target="strong_client_authn"></xref>) や事前登録されたリダイレクトURIの検証 (<xref target="val_redirect"></xref>) のようなその他の認証メカニズムによる認証を受けていないとき, 認可サーバーは繰り返しの認可を自動処理すべきではない.
            </t>
            <!--
            <t>Authorization servers should NOT automatically process repeat
            authorizations where the client is not authenticated through a
            client secret or some other authentication mechanism such as a
            signed authentication assertion certificate
            (<xref target="strong_client_authn"></xref>) or
            validation of a pre-registered redirect URI
            (<xref target="val_redirect"></xref>).</t>
            -->
          </section>

          <section anchor="informed_decisions"
                   title="Informed Decisions Based on Transparency">
            <t>
              認可サーバーはエンドユーザーに認可プロセスで何が起き, 結果がどうなるかを明確に説明すべきである.
              例えば, ユーザーはどのようなアクセス権をどのくらいの期間クライアントに与えようとしているかを理解すべきである.
              またサーバーがそのクライアントの属性 (ウェブサイトURLやセキュリティポリシー) について確実に証明できるかどうかをユーザーに明らかにすべきである.
            </t>
            <!--
            <t>The authorization server should clearly explain to the end user
            what happens in the authorization process and what the
            consequences are. For example, the user should understand what
            access he is about to grant to which client for what duration. It
            should also be obvious to the user whether the server is able to
            reliably certify certain client properties (web site URL, security
            policy).</t>
            -->
          </section>

          <section anchor="validation_end_user"
                   title="Validation of Client Properties by End User">
            <t>
              認可のプロセスでは, ユーザーは典型的にはクライアントからの認可のリクエストの承認を求められる.
              認可サーバーによって認識されているクライアントの名前とユーザーが利用しているウェブサイトやアプリケーションの名前が適合しているかどうかなど, クライアントの属性の検証にエンドユーザーが関与できるため, これは重要なセキュリティメカニズムである.
              この手法は特に認可サーバーがクライアントを認証できない状況のときに有用である.
              これは以下に対する対抗策である:
            </t>
            <!--
            <t>In the authorization process, the user is typically asked to
            approve a client's request for authorization. This is an important
            security mechanism by itself because the end user can be involved
            in the validation of client properties, such as whether the client
            name known to the authorization server fits the name of the web
            site or the application the end user is using. This measure is
            especially helpful in situations where the authorization server is
            unable to authenticate the client. It is a countermeasure
            against:</t>
            -->

            <t>
              <list style="symbols">
                <t>
                  悪意のあるアプリケーション
                </t>

                <t>
                  他のクライアントに成り済ますクライアントアプリケーション
                </t>
              </list></t>
              <!--
              <t><list style="symbols">
                  <t>A malicious application</t>

                  <t>A client application masquerading as another client</t>
                </list></t>
              -->
          </section>

          <section anchor="bind_code_client_id"
                   title="Binding of Authorization &quot;code&quot; to &quot;client_id&quot;">
            <t>
              認可サーバーは全ての認可コードをエンドユーザー認可プロセスを開始したクライアントの識別子と紐づけるべきである.
              この手法は以下に対する対抗策である.
            </t>
            <!--
            <t>The authorization server should bind every authorization "code"
            to the id of the respective client that initiated the end-user
            authorization process. This measure is a countermeasure
            against:</t>
            -->

            <t><list style="symbols">
                <t>
                  異なるクライアントクレデンシャルを用いた認可コードのリプレイ.
                  なぜなら攻撃者は認可コードをトークンに交換するために他の "client_id" を使用することができないため.
                </t>

                <t>
                  認可コードのオンライン推測
                </t>
              </list>
              注: この紐づけは認可なしに変更されないように保護されるべきである
              (例えば, 保護メモリ および／または セキュアデータベースを使用する).
            </t>
            <!--
            <t><list style="symbols">
                <t>Replay of authorization "codes" with different client
                credentials, since an attacker cannot use another "client_id"
                to exchange an authorization "code" into a token</t>

                <t>Online guessing of authorization "codes"</t>
              </list>Note: This binding should be protected from unauthorized
            modifications (e.g., using protected memory and/or a secure
            database).</t>
            -->
          </section>

          <section anchor="bind_code_redirect"
                   title="Binding of Authorization &quot;code&quot; to &quot;redirect_uri&quot;">
            <t>
              認可サーバーは全ての認可コードをエンドユーザー認可プロセスでクライアントへのリダイレクトの宛先として使用される実際のリダイレクトURIと紐づけできるようにすべきである.
              この紐づけは, クライアントが認可コードをアクセストークンに交換しようとした際に, 検証されるべきである.
             攻撃者が認可コードをアクセストークンに交換する際に別のリダイレクトURIを使用することができないため, この方法は偽のウェブサイトへの認可コードの漏洩に対する対抗策となる.
            </t>
            <!--
            <t>The authorization server should be able to bind every
            authorization "code" to the actual redirect URI used as the
            redirect
            target of the client in the end-user authorization process. This
            binding should be validated when the client attempts to exchange
            the respective authorization "code" for an access token. This
            measure is a countermeasure against authorization "code" leakage
            through counterfeit web sites, since an attacker cannot use another
            redirect URI to exchange an authorization "code" into a
            token.</t>
            -->
          </section>
        </section>
      </section>

      <section title="Client App Security">
        <t>
          当セクションはクライアントアプリケーションに対するSecurity Considerationsを扱う.
        </t>
        <!--
        <t>This section deals with considerations for client applications.</t>
        -->

        <section anchor="cred_software"
                 title="Don't Store Credentials in Code or Resources Bundled with Software Packages">
          <t>
            クライアントソフトウェアのコピーは多数作られるため, アプリケーションの全てのインストールで共有される単一のクライアント識別子とシークレットを生成することは, あまりよくない.
            クライアントシークレットが安全に保持されるとは言えないため, このようなアプリケーションはパブリッククライアントと見なされるだろう.
            アプリケーションのソースコードや関連のリソースバンドルに埋め込まれたシークレットは, リバースエンジニアリングに対しては無力である.
            次に, このようなシークレットを無効化すると, そのアプリケーションの全てのインストールが即座に動作しなくなってしまうため, 無効化することができない.
            さらに, 認可サーバーはクライアント識別子を実際には信用できないため, そのクライアントの信頼性をエンドユーザに示すことは危険だろう.
          </t>
          <!--
          <t>Because of the number of copies of client software, there is
          limited benefit in creating a single client id and secret that is
          shared by all installations of an application. Such an application
          by itself would be considered a "public" client, as it cannot be
          presumed to be able to keep client secrets. A secret, burned into
          the source code of the application or an associated resource bundle,
          cannot be protected from reverse engineering. Secondly, such secrets
          cannot be revoked, since this would immediately put all installations
          out of work. Moreover, since the authorization server cannot really
          trust the client's identifier, it would be dangerous to indicate to
          end users the trustworthiness of the client.</t>
          -->
        </section>

        <section anchor="std_web"
                 title="Use Standard Web Server Protection Measures (for Config Files and Databases)">
          <t>
            サーバーやデータベース, 設定ファイル, その他のサーバーの運用に関わるコンポーネントの完全性を保護するために, 標準的なウェブサーバーの保護と設定方法を使うこと.
          </t>
          <!--
          <t>Use standard web server protection and configuration measures to
          protect the integrity of the server, databases, configuration files,
          and other operational components of the server.</t>
          -->

        </section>

        <section anchor="secure_storage"
                 title="Store Secrets in Secure Storage">
          <t>
            あらゆる種類のシークレット (トークン, クライアントシークレット) を安全にデバイスやサーバーに格納する方法は複数存在する.
          </t>
          <!--
          <t>There are different ways to store secrets of all kinds (tokens,
          client secrets) securely on a device or server.</t>
          -->

          <t>
            ほとんどのマルチユーザーオペレーティングシステムは個々のシステムユーザーの個人ストレージをそれぞれ分離して管理している.
            さらに, 最近のスマートフォンのオペレーティングシステムのほとんどはファイルシステムの分離された領域にアプリケーション固有のストレージまでも用意され, 他のアプリケーションからアクセスできないようになっている.
            加えて, アプリケーションはPINやパスワードといったユーザーが提供するシークレットを用いてデータの秘匿性を実現することもできる.
          </t>
          <!--
          <t>Most multi-user operating systems segregate the personal storage
          of different system users. Moreover, most modern smartphone
          operating systems even support the storage of application-specific data in
          separate areas of file systems and protect the data from access by
          other applications. Additionally, applications can implement
          confidential data by using a user-supplied secret, such as a
          PIN or password.</t>
          -->

          <t>
            別の方法としてリフレッシュトークンを信頼できるバックエンドサーバーに保管する方法が挙げられる.
            この方法ではクライアントとバックエンドサーバー間の強固な認証機構が必要となる.
            注: アプリケーションは, 秘匿データがセキュアストレージから読み出された後でも秘匿性を保持したままであることを保証すべきである.
            これは典型的にはこのデータをアプリケーションのローカルメモリ内で保持することを意味する.
          </t>
          <!--
          <t>Another option is to swap refresh token storage to a trusted
          backend server. This option in turn requires a resilient
          authentication mechanism between the client and backend server.
          Note: Applications should ensure that confidential data is kept
          confidential even after reading from secure storage, which typically
          means keeping this data in the local memory of the application.</t>
          -->
        </section>

        <section anchor="device_lock"
                 title="Utilize Device Lock to Prevent Unauthorized Device Access">
          <t>
            典型的な最近の電話機では, デバイスを盗難された場合や置き忘れた場合に有用な追加の保護機構を持っている.
            これらはPINやパスワード, 顔認識のようなその他の生体情報を利用する.
            これらが提供するセキュリティレベルはそれぞれ同等ではない.
          </t>
          <!--
          <t>On a typical modern phone, there are many "device lock" options
          that can be utilized to provide additional protection when a
          device is stolen or misplaced. These include PINs, passwords, and
          other biometric features such as "face recognition". These are not
          equal in the level of security they provide.</t>
          -->
        </section>

        <section anchor="link_state_uasession"
                 title="Link the &quot;state&quot; Parameter to User Agent Session">
          <t>
            "state" パラメーターはクライアントに対する複数のリクエスト間を紐づけたり, リダイレクトURIなどに対するCSRF攻撃を防止するために使用される.
            攻撃者は彼ら自身の認可コードやアクセストークンをインジェクションすることが考えられ, その結果, 被害者のではなく攻撃者の保護リソースに関連づけられたアクセストークンをクライアントに使わせることになる (例えば, 被害者の銀行口座情報を攻撃者の制御下にある保護リソースに保存).
          </t>
          <!--
          <t>The "state" parameter is used to link client requests and prevent
          CSRF attacks, for example, attacks against the redirect URI.
          An attacker could inject their own authorization "code" or
          access token, which can
          result in the client using an access token associated with the
          attacker's protected resources rather than the victim's (e.g., save
          the victim's bank account information to a protected resource
          controlled by the attacker).</t>
          -->

          <t>
            クライアントは認可リクエストを作成する際, ユーザーエージェントの認証状態をリクエストに紐づけた値  (例えばユーザーエージェントの認証に用いたセッションクッキーのハッシュ) を認可サーバーに送るために "state" リクエストパラメーターを利用すべきである.
            エンドユーザーの認可が得られた後, 認可サーバーはリクエストに含まれているものと同じ値を持つ "state" パラメーターを付与し, エンドユーザーのユーザーエージェントをクライアントにリダイレクトバックさせる.
          </t>
          <!--
          <t>The client should utilize the "state" request parameter to send
          the authorization server a value that binds the request to the
          user agent's authenticated state (e.g., a hash of the session
          cookie used to authenticate the user agent) when making an
          authorization request. Once authorization has been obtained from
          the end user, the authorization server redirects the end-user's
          user agent back to the client with the required binding value
          contained in the "state" parameter.</t>
          -->

          <t>
            この紐づけられた値とユーザーエージェントの認証状態のマッチングを行うことにより, クライアントはリクエストの妥当性を検証することができる.
          </t>
          <!--
          <t>The binding value enables the client to verify the validity of
          the request by matching the binding value to the user agent's
          authenticated state.</t>
          -->
        </section>
      </section>

      <section title="Resource Servers">
        <t>
          以下はリソースサーバーのsecurity considerationsについて詳述する.
        </t>
        <!--
        <t>The following section details security considerations for resource
        servers.</t>
        -->

        <section anchor="authz_header" title="Authorization Headers">
          <t>
            AuthorizationヘッダーはHTTPプロクシとサーバーによって認識され, 特別に取り扱われる.
            アクセストークンをリソースサーバーに送るためにそのようなヘッダー, 特にAuthorizationヘッダーを用いることは, 一般に認証済リクエストが意図せず保存されたり漏洩する可能性を減らす.
          </t>
          <!--
          <t>Authorization headers are recognized and specially treated by
          HTTP proxies and servers. Thus, the usage of such headers for sending
          access tokens to resource servers reduces the likelihood of leakage
          or unintended storage of authenticated requests in general, and
          especially Authorization headers.</t>
          -->
        </section>

        <section anchor="authn_requests" title="Authenticated Requests">
          <t>
            認可サーバーは, トークンに特定のクライアント識別子を紐づけし, リソースアクセスの際にリソースサーバーがその紐づけを検証可能とすることもできる.
            その際リソースサーバーは, リクエスト送信者がトークンの正規のオーナーであることを確認するため, リクエスト送信者の認証が必要になる.
            この対抗策を実装する方法はいくつかある:
          </t>
          <!--
          <t>An authorization server may bind tokens to a certain client
          identifier and enable resource servers to validate that
          association on resource access. This will require the resource
          server to authenticate the originator of a request as the legitimate
          owner of a particular token. There are several options to
          implement this countermeasure:</t>
          -->

          <t>
            <list style="symbols">
              <t>
                認可サーバーはクライアント識別子を (内部的に, またはself-containedトークンのペイロード内で) トークンに関連づけるかもしれない.
                そしてクライアントは自身のアイデンティティを認証するためにリソースサーバーのエンドポイントに対し, クライアント証明書を用いたHTTP認証を行う.
                そしてリソースサーバーはトークンによって参照されている名前と, 証明書の名前の照合を行う.
              </t>

              <t>
                クライアントはリソースサーバーへのリクエストの署名に秘密鍵を用いる (公開鍵はトークン内に格納するか, リクエストとともに送信する).
              </t>

              <t>
                認可サーバーはトークンに紐づけられた鍵を発行し, クライアントはトークン使用に対する認証のためのHolder-of-Key証明にその鍵を使用する方法もありうる.
                リソースサーバーは認可サーバーから直接シークレットを取得するか, シークレットはトークンの暗号化領域に格納されている.
                この方法ではリソースサーバーはクライアントが誰であるかを知らないが, 認可サーバーがトークンをそのクライアントに対して発行したかどうかを検証することができる.
              </t>
            </list>
            認証済リクエストは偽のリソースサーバーによるトークンの悪用に対する対抗策となる.
          </t>
          <!--
          <t><list style="symbols">
              <t>The authorization server may associate the client identifier
              with the token (either internally or in the payload of a
              self-contained token). The client then uses client
              certificate-based HTTP authentication on the resource server's
              endpoint to authenticate its identity, and the resource server
              validates the name with the name referenced by the token.</t>

              <t>Same as the option above, but the client uses his
              private key to sign
              the request to the resource server (the public key is either
              contained in the token or sent along with the request).</t>

              <t>Alternatively, the authorization server may issue a
              token-bound key, which the client uses in a
              Holder-of-Key proof to authenticate the client's use of the
              token. The resource server obtains the secret directly from
              the authorization server, or the secret is contained in an
              encrypted section of the token. In that way, the resource
              server does not "know" the client but is
              able to validate whether the authorization server issued the
              token to that client.</t>
            </list>Authenticated requests are a countermeasure against abuse
          of tokens by counterfeit resource servers.</t>
          -->
        </section>

        <section anchor="signed_requests" title="Signed Requests">
          <t>
            トランスポートレベルのセキュリティ手法の置き換えや, そのような手法の補完のために, リソースサーバーは署名されたリクエストのみを受け付けるよう決定するかもしれない.
            全ての署名されたリクエストはユニークに識別できるべきであり, リソースサーバーによって二度処理されることがないようにすべきである.
            この対抗策は以下についての軽減を助ける:
          </t>
          <!--
          <t>A resource server may decide to accept signed requests only,
          either to replace transport-level security measures or to complement
          such measures. Every signed request should be uniquely identifiable
          and should not be processed twice by the resource server. This
          countermeasure helps to mitigate:</t>
          -->

          <t>
            <list style="symbols">
              <t>
                メッセージの改竄
              </t>

              <t>
                リプレイの試行
              </t>
            </list>
          </t>
          <!--
          <t><list style="symbols">
              <t>modifications of the message and</t>

              <t>replay attempts</t>
            </list></t>
          -->
        </section>
      </section>

      <section anchor="installed_apps"
               title="A Word on User Interaction and User-Installed Apps">
        <t>
          セキュリティプロトコルとしてOAuthは, エンドユーザーをセキュリティモデルの一部とし, 重要なユーザー対話をフロー中に通常含んでいるという点が独特である.
          これが上記で説明された脅威のいくつかに対する防御の困難さを生み出している.
          これらの点のうちいくつかは既に説明してきたが, ここでふたたび繰り返して焦点をあてる価値はある.
        </t>
        <!--
        <t>OAuth, as a security protocol, is distinctive in that its flow
        usually involves significant user interaction, making the end user a
        part of the security model. This creates some important difficulties
        in defending against some of the threats discussed above. Some of
        these points have already been made, but it's worth repeating and
        highlighting them here.</t>
        -->

        <t>
          <list style="symbols">
            <t>
              エンドユーザーは何の承認を尋ねられているかを理解しなければならない
              (<xref target="informed_decisions"></xref> 参照).
              ユーザーは認可リクエストに対し "yes" と答えることによる悪影響を理解するだけの専門知識を持っていないことも多く, リクエストの言い回しの微妙な違いを理解することができないこともありそうである.
              悪意のあるソフトウェアはユーザーをだましてほとんどどんなものでも承認させて, ユーザーを混乱させることができる.
            </t>

            <t>
              エンドユーザーのデバイスはソフトウェアが脆弱な状態になりがちである.
              これは, ウェブブラウザやユーザーシステムのその他の部分に対する頻繁な攻撃とともに, 以前からある長期に渡る問題である.
              ユーザーによってインストールされるアプリの人気が増加するにつれ, 脆弱性や悪意のあるエンドユーザーソフトウェアによりもたらされる脅威は非常に強くなり, 軽減することがとても困難である.
            </t>

            <t>
              ユーザーがこのようなアプリのインストールと実行を望むであろうこと, および, 信頼できないアプリや悪意のあるアプリがデータフロー中の様々な箇所でクレデンシャルを窃取することができる, ということを認識すること.
              それらのアプリは, OAuthが設計上保護することになっているユーザーのログインクレデンシャルを傍受し, ユーザが理解し承認した範囲をはるかに超えた認可をリクエストし, ユーザーの代わりにレスポンスをひっそりと自動的に処理することができる.
              これらに対する知られた解決方法は存在しないため, ここでは示さない.
              これはよりよいセキュリティとよりよいユーザビリティの狭間に存在している.
            </t>

            <t>
              ユーザーがインストールするソフトウェアの使用を制限することによってこれらの問題を解決することは限られた環境では実用的で, これらのケースに対する対抗策として利用できるかもしれない.
              しかしこのような制約は一般的なケースでは実用的ではなく, 事後のリカバリ方法が用意されるべきである.
            </t>

            <t>
              エンドユーザーは自身のデバイスにロードしたアプリケーションに関して適切な審査を行う能力に欠けるかもしれないが, 認可サーバーの提供者が悪意あるクライアントによる被害を軽減するためになにかしらのツールを利用することもできる.
              例えば, よい認可サーバーは, 各クライアント属性について有効に検証できたものとできなかったものを明確に示し, そのクライアントのアクセスを許可することのリスクを提示するに違いない.
            </t>
          </list>
        </t>
        <!--
        <t><list style="symbols">
            <t>End users must understand what they are being asked to approve
            (see <xref target="informed_decisions"></xref>). Users
            often do not have the expertise to understand the ramifications of
            saying "yes" to an authorization request and are likely not to be
            able to see subtle differences in the wording of requests.
            Malicious software can confuse the user, tricking the user into
            approving almost anything.</t>

            <t>End-user devices are prone to software compromise. This has
            been a long-standing problem, with frequent attacks on web
            browsers and other parts of the user's system. But with the
            increasing popularity of user-installed "apps", the threat
            posed by compromised or malicious end-user software is very strong
            and is one that is very difficult to mitigate.</t>

            <t>Be aware that users will demand to install and run such apps,
            and that compromised or malicious ones can steal credentials at
            many points in the data flow. They can intercept the very user
            login credentials that OAuth is designed to protect. They can
            request authorization far beyond what they have led the user to
            understand and approve. They can automate a response on behalf of
            the user, hiding the whole process. No solution is offered here,
            because none is known; this remains in the space between better
            security and better usability.</t>

            <t>Addressing these issues by restricting the use of
            user-installed software may be practical in some limited
            environments and can be used as a countermeasure in those cases.
            Such restrictions are not practical in the general case, and
            mechanisms for after-the-fact recovery should be in place.</t>

            <t>While end users are mostly incapable of properly vetting
            applications they load onto their devices, those who deploy
            authorization servers might have tools at their disposal to
            mitigate malicious clients. For example, a well-run authorization
            server must only assert client properties to the end user it is
            effectively capable of validating, explicitly point out which
            properties it cannot validate, and indicate to the end user the
            risk associated with granting access to the particular client.</t>
          </list></t>
        -->
      </section>
    </section>

    <section anchor="Acknowledgements" title="Acknowledgements">
      <t>We would like to thank Stephen Farrell, Barry Leiba, Hui-Lan Lu,
      Francisco Corella, Peifung E. Lam, Shane B. Weeden, Skylar Woodward, Niv
      Steingarten, Tim Bray, and James H. Manger for their comments and
      contributions.</t>
    </section>
  </middle>

  <back>
  <?rfc rfcedstyle="no"?>
    <references title="Normative References">

<!-- draft-ietf-oauth-v2 published as RFC 6749 October 2012 -->
      <?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.6749.xml' ?>

<!-- draft-ietf-oauth-v2-bearer published as RFC 6750 October 2012 -->
      <?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.6750.xml' ?>
    </references>

    <references title="Informative References">
<!-- draft-ietf-oauth-revocation (I-D Exists) -->
<reference anchor='OAuth-REVOCATION'>
<front>
<title>Token Revocation</title>
<author initials='T' surname='Lodderstedt' fullname='Torsten Lodderstedt' role="editor">
    <organization />
</author>
<author initials='S' surname='Dronia' fullname='Stefanie Dronia'>
    <organization />
</author>
<author initials='M' surname='Scurtescu' fullname='Marius Scurtescu'>
    <organization />
</author>
<date month='November' year='2012' />
</front>
<seriesInfo name='Work in' value='Progress' />
</reference>

<!-- draft-ietf-oauth-v2-http-mac (I-D Exists) -->
<reference anchor='OAuth-HTTP-MAC'>
<front>
<title>OAuth 2.0 Message Authentication Code (MAC) Tokens</title>
<author initials='J' surname='Richer' fullname='Justin Richer' role="editor">
    <organization />
</author>
<author initials='W' surname='Mills' fullname='William Mills' role="editor">
    <organization />
</author>
<author initials='H' surname='Tschofenig' fullname='Hannes Tschofenig' role="editor">
    <organization />
</author>
<date month='November' year='2012' />
</front>
<seriesInfo name='Work in' value='Progress' />
</reference>

<!-- draft-ietf-oauth-assertions (Waiting for AD Go-Ahead) -->
<reference anchor='OAuth-ASSERTIONS'>
<front>
<title>Assertion Framework for OAuth 2.0</title>
<author initials='B' surname='Campbell' fullname='Brian Campbell'>
    <organization />
</author>
<author initials='C' surname='Mortimore' fullname='Chuck Mortimore'>
    <organization />
</author>
<author initials='M' surname='Jones' fullname='Michael Jones'>
    <organization />
</author>
<author initials='Y' surname='Goland' fullname='Yaron Goland'>
    <organization />
</author>
<date month='December' year='2012' />
</front>
<seriesInfo name='Work in' value='Progress' />
</reference>

<!-- draft-ietf-oauth-json-web-token (I-D Exists) -->
<reference anchor='OAuth-JWT'>
<front>
<title>JSON Web Token (JWT)</title>
<author initials='M' surname='Jones' fullname='Michael Jones'>
    <organization />
</author>
<author initials='J' surname='Bradley' fullname='John Bradley'>
    <organization />
</author>
<author initials='N' surname='Sakimura' fullname='Nat Sakimura'>
    <organization />
</author>
<date month='December' year='2012' />
</front>
<seriesInfo name='Work in' value='Progress' />
</reference>

<!-- draft-ietf-websec-x-frame-options -->
<!-- (formerly draft-gondrom-x-frame-options (AD is watching) -->
<reference anchor='X-Frame-Options'>
<front>
<title>HTTP Header X-Frame-Options</title>
<author initials='D' surname='Ross' fullname='David Ross'>
    <organization />
</author>
<author initials='T' surname='Gondrom' fullname='Tobias Gondrom'>
    <organization />
</author>
<date month='October' year='2012' />
</front>
<seriesInfo name='Work in' value='Progress' />
</reference>

      <?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.4086.xml' ?>

      <?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.2616.xml' ?>

      <?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.5246.xml' ?>

      <?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.4301.xml' ?>

      <?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.2818.xml' ?>

      <?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.4120.xml' ?>

<reference anchor="OASIS.saml-core-2.0-os" target="http://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf">
<front>
<title>Assertions and Protocols for the OASIS Security Assertion Markup
Language (SAML) V2.0</title>
<author fullname="Scott Cantor" initials="S." surname="Cantor" role="editor">
</author>
<author fullname="John Kemp" initials="J." surname="Kemp" role="editor">
</author>
<author fullname="Rob Philpott" initials="R." surname="Philpott" role="editor">
</author>
<author fullname="Eve Maler" initials="E." surname="Maler" role="editor">
</author>
<date year="2005" month="March"/>
</front>
<seriesInfo name="OASIS Standard" value="saml-core-2.0-os"/>
</reference>

      <reference anchor="Framebusting" target="http://elie.im/publication/busting-frame-busting-a-study-of-clickjacking-vulnerabilities-on-popular-sites">
        <front>
          <title>Busting Frame Busting: a Study of Clickjacking
          Vulnerabilities on Popular Sites</title>
          <author fullname="G. Rydstedt" initials="G" surname="Rydstedt">
          </author>
          <author fullname="E. Bursztein" surname="Bursztein">
          </author>
          <author fullname="D. Boneh" initials="D" surname="Boneh">
          </author>
          <author fullname="C. Jackson" initials="C" surname="Jackson">
          </author>
          <date month="May" year="2010" />
        </front>
        <seriesInfo name="IEEE"
                    value="3rd Web 2.0 Security and Privacy Workshop" />
      </reference>

      <reference anchor="iFrame" target="http://www.w3.org/TR/html4/present/frames.html#h-16.5">
        <front>
          <title>Frames in HTML documents</title>
          <author>
            <organization>World Wide Web Consortium</organization>
          </author>
          <date month="December" year="1999" />
        </front>
        <seriesInfo name="W3C" value="HTML 4.01" />
      </reference>

      <reference anchor="IMEI" target="http://www.3gpp.org/ftp/Specs/html-info/22016.htm">
        <front>
          <title>International Mobile station Equipment Identities
          (IMEI)</title>
          <author>
            <organization>3GPP</organization>
          </author>
          <date month="September" year="2012" />
        </front>
        <seriesInfo name="3GPP TS" value="22.016 11.0.0" />
      </reference>

      <reference anchor="OWASP" target="https://www.owasp.org/">
        <front>
          <title>Open Web Application Security Project Home Page</title>
          <author></author>
          <date />
        </front>
      </reference>

      <reference anchor="OPENID" target="http://openid.net/">
        <front>
          <title>OpenID Foundation Home Page</title>
          <author></author>
          <date />
        </front>
      </reference>

      <reference anchor="Portable-Contacts"
                 target="http://portablecontacts.net/">
        <front>
          <title>Portable Contacts 1.0 Draft C</title>
          <author fullname="J. Smarr" initials="J" surname="Smarr">
          </author>
          <date month="August" year="2008" />
        </front>
      </reference>

      <reference anchor="Sec-Analysis">
        <front>
          <title>Security Analysis of the SAML Single Sign-on Browser/Artifact
          Profile</title>
          <author fullname="T. Gro&szlig;" initials="T" surname="Gro&szlig;">
          </author>
          <date month="December" year="2003" />
        </front>
       <seriesInfo name="19th Annual Computer Security Applications Conference," value="Las Vegas"/>
      </reference>

      <reference anchor="OASIS.sstc-saml-bindings-1.1" target="http://www.oasis-open.org/committees/download.php/3405/oasis-sstc-saml-bindings-1.1.pdf">
        <front>
          <title>Bindings and Profiles for the OASIS Security Assertion Markup
          Language (SAML) V1.1</title>
          <author fullname="E. Maler" initials="E." role="editor"
                  surname="Maler"></author>
          <author fullname="P. Mishra" initials="P." role="editor"
                  surname="Mishra"></author>
          <author fullname="R. Philpott" initials="R." role="editor"
                  surname="Philpott"></author>
          <date month="September" year="2003" />
        </front>
      </reference>

      <reference anchor="OASIS.sstc-sec-analysis-response-01" target="http://www.oasis-open.org/committees/download.php/11191/sstc-gross-sec-analysis-response-01.pdf">
        <front>
          <title>SSTC Response to &ldquo;Security Analysis of the SAML Single
          Sign-on Browser/Artifact Profile&rdquo;</title>
          <author fullname="J. Linn" initials="J." role="editor"
                  surname="Linn"></author>
          <author fullname="P. Mishra" initials="P." role="editor"
                  surname="Mishra"></author>
          <date month="January" year="2005" />
        </front>
      </reference>

      <reference anchor="SSL-Latency">
        <front>
          <title>SSL handshake latency and HTTPS optimizations</title>
          <author fullname="Jordan Sissel" initials="J." role="editor"
                  surname="Sissel"></author>
          <date month="June" year="2010" />
        </front>
      </reference>

    </references>

    <references title='翻訳プロジェクト'>
      <reference anchor="oidfj">
        <front>
          <title>OpenIDファウンデーションジャパン</title>
          <author>
            <organization>OpenIDファウンデーションジャパン</organization>
          </author>
        </front>
        <format type='html' target='http://www.openid.or.jp/' />
      </reference>
      <reference anchor="oidfj-trans">
        <front>
          <title>翻訳・教育ワーキンググループ</title>
          <author>
            <organization>OpenIDファウンデーションジャパン</organization>
          </author>
        </front>
        <format type='html' target='http://openid-foundation-japan.github.com/' />
      </reference>
      <reference anchor="oidfj-github">
        <front>
          <title>Githubレポジトリー</title>
          <author>
            <organization>OpenIDファウンデーションジャパン</organization>
          </author>
        </front>
        <format type='html' target='https://github.com/openid-foundation-japan' />
      </reference>
    </references>

    <section title="翻訳者">
      <t>
        本仕様の翻訳は, <xref target='oidfj'>OpenIDファウンデーションジャパン</xref> <xref target='oidfj-trans'>翻訳・教育ワーキンググループ</xref>を主体として, 有志のメンバーによって行われました.
        質問や修正依頼などについては, <xref target='oidfj-github'>Githubレポジトリー</xref> にご連絡ください.
      </t>
      <t>
        <list style='symbols'>
          <t>
            Nov Matake
          </t>
          <t>
            Satoshi Yagi
          </t>
        </list>
      </t>
    </section>

  <?rfc rfcedstyle="yes"?>
  </back>
</rfc>