メインコンテンツまでスキップ

2. クライアント登録 (Client Registration)

プロトコルを開始する前に、クライアントは認可サーバー (Authorization Server) に登録します。クライアントが認可サーバーに登録する方法は本仕様の範囲外ですが、通常はエンドユーザーとHTML登録フォームとのインタラクションが含まれます。

クライアント登録では、クライアントと認可サーバー間の直接的なインタラクションは必須ではありません (MUST NOT)。認可サーバーがサポートする場合、登録は他の手段に依存して信頼関係を確立し、クライアントのプロパティ (リダイレクトURI、クライアントタイプなど) を取得することができます。たとえば、登録は自己発行または第三者発行のアサーションを使用して完了することも、認可サーバーが信頼されたチャネルを使用してクライアント検出を実行することによって完了することもできます。

クライアントを登録する際、クライアント開発者は次のことを行うべきです (SHOULD)。

  • セクション2.1で説明されているクライアントタイプを指定する
  • セクション3.1.2で説明されているクライアントリダイレクトURIを提供する
  • 認可サーバーが要求するその他の情報 (アプリケーション名、ウェブサイト、説明、ロゴ画像、法的条項の承認など) を含める

2.1. クライアントタイプ (Client Types)​

クライアントが認可サーバーと安全に認証を行う能力 (すなわち、クライアント認証情報の機密性を維持する能力) に基づいて、OAuth は2つのクライアントタイプを定義します。

機密クライアント (Confidential Client)
その認証情報の機密性を維持できるクライアント (たとえば、クライアントが、クライアント認証情報へのアクセスが制限された安全なサーバー上で実行される場合)、または他の手段を使用してクライアント認証の安全性を確保できるクライアント。

パブリッククライアント (Public Client)
その認証情報の機密性を維持できないクライアント (たとえば、リソースオーナーが使用するデバイス上で実行されるクライアント。インストールされたネイティブアプリケーションやウェブブラウザベースのアプリケーションなど)、および他の手段を使用してクライアント認証の安全性を確保できないクライアント。

クライアントタイプの選択は、認可サーバーのセキュリティ認証の定義と、クライアント認証情報への許容可能な露出レベルに基づいています。認可サーバーは、クライアントタイプについて想定を行うべきではありません (SHOULD NOT)。

クライアントは、それぞれ異なるクライアントタイプとセキュリティコンテキストを持つ分散コンポーネントのセットとして実装される可能性があります (たとえば、機密サーバーベースのコンポーネントとパブリックブラウザベースのコンポーネントの両方を持つ分散クライアント)。認可サーバーがこのようなクライアントをサポートしていない場合、またはそのような登録に関するガイダンスを提供していない場合、クライアントは各コンポーネントを個別のクライアントとして登録すべきです (SHOULD)。

本仕様は、以下のクライアント構成を中心に設計されています。

ウェブアプリケーション (Web Application)
ウェブアプリケーションは、ウェブサーバー上で実行される機密クライアントです。リソースオーナーは、デバイス上のユーザーエージェント内でレンダリングされるHTMLユーザーインターフェースを介してクライアントにアクセスします。クライアント認証情報およびクライアントに発行されたアクセストークンは、ウェブサーバー上に保存され、リソースオーナーに公開されたり、リソースオーナーがアクセス可能になったりすることはありません。

ユーザーエージェントベースのアプリケーション (User-Agent-Based Application)
ユーザーエージェントベースのアプリケーションは、パブリッククライアントです。クライアントのコードはウェブサーバーからダウンロードされ、リソースオーナーが使用するデバイス上のユーザーエージェント (ウェブブラウザなど) 内で実行されます。プロトコルデータと認証情報は、リソースオーナーが簡単にアクセスできます (しばしば表示されます)。これらのアプリケーションはユーザーエージェント内に存在するため、認可をリクエストする際にユーザーエージェントの機能をシームレスに使用できます。

ネイティブアプリケーション (Native Application)
ネイティブアプリケーションは、リソースオーナーが使用するデバイス上にインストールされ実行されるパブリッククライアントです。プロトコルデータと認証情報は、リソースオーナーがアクセス可能です。アプリケーションに含まれる任意のクライアント認証認証情報は抽出可能であると想定されます。一方、アクセストークンやリフレッシュトークン (Refresh Token) などの動的に発行される認証情報は、許容可能なレベルの保護を達成できます。少なくとも、これらの認証情報は、アプリケーションが対話する可能性のある悪意のあるサーバーから保護されます。一部のプラットフォームでは、これらの認証情報を同じデバイス上に存在する他のアプリケーションから保護することもできます。

2.2. クライアント識別子 (Client Identifier)​

認可サーバーは、登録されたクライアントにクライアント識別子 (Client Identifier) を発行します。これは、クライアントが提供した登録情報を表す一意の文字列です。クライアント識別子は秘密ではありません。リソースオーナーに公開され、クライアント認証に単独で使用してはなりません (MUST NOT)。クライアント識別子は、認可サーバーに対して一意です。

クライアント識別子文字列のサイズは、本仕様では定義されていません。クライアントは、識別子のサイズについて想定を避けるべきです (SHOULD)。認可サーバーは、発行する識別子のサイズをドキュメント化すべきです (SHOULD)。

2.3. クライアント認証 (Client Authentication)​

クライアントタイプが機密である場合、クライアントと認可サーバーは、認可サーバーのセキュリティ要件に適したクライアント認証方法を確立します。認可サーバーは、そのセキュリティ要件を満たす任意の形式のクライアント認証を受け入れることができます (MAY)。

機密クライアントには通常、認可サーバーとの認証に使用するクライアント認証情報のセット (パスワード、公開鍵/秘密鍵ペアなど) が発行 (または確立) されます。認可サーバーは、パブリッククライアントとクライアント認証方法を確立することができます (MAY)。ただし、認可サーバーは、クライアントを識別する目的でパブリッククライアント認証に依存してはなりません (MUST NOT)。

クライアントは、各リクエストで複数の認証方法を使用してはなりません (MUST NOT)。

2.3.1. クライアントパスワード (Client Password)​

クライアントパスワードを持つクライアントは、<RFC2617> で定義されている HTTP Basic 認証スキームを使用して認可サーバーと認証を行うことができます (MAY)。クライアント識別子は、Appendix B の application/x-www-form-urlencoded エンコーディングアルゴリズムを使用してエンコードされ、エンコードされた値がユーザー名として使用されます。クライアントパスワードは同じアルゴリズムを使用してエンコードされ、パスワードとして使用されます。認可サーバーは、クライアントパスワードが発行されたクライアントを認証するために HTTP Basic 認証スキームをサポートしなければなりません (MUST)。

たとえば (追加の改行は表示目的のみ):

Authorization: Basic czZCaGRSa3F0Mzo3RmpmcDBaQnIxS3REUmJuZlZkbUl3

あるいは、認可サーバーは、リクエストボディに次のパラメータを含めることでクライアント認証情報をサポートすることができます (MAY)。

client_id
必須である (REQUIRED)。セクション2.2で説明されているように、登録プロセス中にクライアントに発行されたクライアント識別子。

client_secret
必須である (REQUIRED)。クライアントシークレット。クライアントシークレットが空の文字列である場合、クライアントはこのパラメータを省略することができます (MAY)。

リクエストボディにこれら2つのパラメータを含めることでクライアント認証情報を含めることは推奨されません (NOT RECOMMENDED)。HTTP Basic 認証スキーム (または他のパスワードベースの HTTP 認証スキーム) を直接使用できないクライアントに限定すべきです (SHOULD)。パラメータはリクエストボディにのみ送信でき、リクエスト URI に含めることはできません (MUST NOT)。

たとえば、リクエストボディパラメータを使用してアクセストークンをリフレッシュする (セクション6) (追加の改行は表示目的のみ):

POST /token HTTP/1.1
Host: server.example.com
Content-Type: application/x-www-form-urlencoded

grant_type=refresh_token&refresh_token=tGzv3JOkF0XG5Qx2TlKWIA
&client_id=s6BhdRkqt3&client_secret=7Fjfp0ZBr1KtDRbnfVdmIw

パスワード認証を使用してリクエストを送信する場合、認可サーバーは、セクション1.6で説明されているように TLS の使用を要求しなければなりません (MUST)。

このクライアント認証方法にはパスワードが含まれるため、認可サーバーは、パスワードを使用するすべてのエンドポイントをブルートフォース攻撃から保護しなければなりません (MUST)。

2.3.2. その他の認証方法 (Other Authentication Methods)​

認可サーバーは、セキュリティ要件を満たす任意の適切な HTTP 認証スキームをサポートすることができます (MAY)。公開鍵/秘密鍵ペアを使用する場合、認可サーバーは、RFC 2617 で定義されている HTTP Digest 認証スキームを使用しなければなりません (MUST)。

2.4. 未登録のクライアント (Unregistered Clients)​

本仕様は、未登録のクライアントの使用を想定していません。ただし、認可サーバーは、そのようなクライアントをサポートすることができます (MAY)。

未登録のクライアントを使用する場合、クライアント識別子は本仕様で定義されていない他の方法で取得されます。認可サーバーは、未登録のクライアントの使用に関する要件と制限をドキュメント化すべきです (SHOULD)。

に最終更新