<p>style_prompt本記事は<strong>Geminiの出力をプロンプト工学で整理した業務ドラフト（未検証）</strong>です。</p>
<h1 class="wp-block-heading">令和5年度 秋期 情報処理安全確保支援士 午前Ⅱ 問5 OAuth 2.0</h1>
<p>OAuth 2.0においてリソース所有者の権限をアプリに委譲する際に使用される、アクセストークンの性質と発行プロセスを解説します。</p>
<blockquote class="wp-block-quote is-layout-flow wp-block-quote-is-layout-flow">
<p>OAuth 2.0において，認可サーバがアクセストークンを発行し，クライアントがそのアクセストークンを利用してリソースサーバからリソースを取得する手順はどれか。</p>
<p>ア 認可サーバがリソースサーバにアクセストークンを送信し，リソースサーバがクライアントにそのアクセストークンを送信する。
イ クライアントが認可サーバにアクセストークンの発行を要求し，認可サーバがクライアントにアクセストークンを送信する。
ウ クライアントがリソースサーバに認可コードを送信し，リソースサーバが認可サーバからアクセストークンを取得する。
エ リソースサーバが認可サーバにアクセストークンの発行を要求し，認可サーバがクライアントにアクセストークンを送信する。</p>
</blockquote>
<p>【解説】
OAuth 2.0は、サードパーティ製のアプリケーション（クライアント）が、ユーザ（リソース所有者）に代わってHTTPサービス上のリソースへアクセスできるようにする認可フレームワークです。</p>
<p>基本的な「認可コードグラント」のフローにおいて、アクセストークンの発行と利用は以下の流れで行われます。</p>
<ol class="wp-block-list">
<li><p>クライアントがユーザから認可を得て「認可コード」を取得する。</p></li>
<li><p>クライアントが<strong>認可サーバに対して認可コードを提示し、アクセストークンの発行を要求</strong>する。</p></li>
<li><p>認可サーバがクライアントに対して<strong>アクセストークンを発行（送信）</strong>する。</p></li>
<li><p>クライアントがそのアクセストークンを<strong>リソースサーバに提示</strong>してリソースを取得する。</p></li>
</ol>
<div class="wp-block-merpress-mermaidjs diagram-source-mermaid"><pre class="mermaid">
sequenceDiagram
participant C as Client
participant "A as Authorization Server"
participant "R as Resource Server"
C ->> A: Request Access Token (with Auth Code)
A -->> C: Issue Access Token
C ->> R: Access Resource (with Access Token)
R -->> C: Protected Resource
</pre></div>
<p>【選択肢の吟味】</p>
<figure class="wp-block-table"><table>
<thead>
<tr>
<th>選択肢</th>
<th>判定</th>
<th>解説</th>
</tr>
</thead>
<tbody>
<tr>
<td>ア</td>
<td>×</td>
<td>アクセストークンは認可サーバからクライアントへ直接渡されます。リソースサーバを経由することはありません。</td>
</tr>
<tr>
<td>イ</td>
<td><strong>〇</strong></td>
<td>正解。クライアントが認可サーバに要求し、認可サーバがクライアントへトークンを返却するのが正しい手順です。</td>
</tr>
<tr>
<td>ウ</td>
<td>×</td>
<td>認可コードは、クライアントが認可サーバからアクセストークンを取得するために使用する一時的なコードです。</td>
</tr>
<tr>
<td>エ</td>
<td>×</td>
<td>トークンの発行を要求する主体はクライアントです。リソースサーバは提示されたトークンを検証する役割を担います。</td>
</tr>
</tbody>
</table></figure>
<p>【ポイント】</p>
<ul class="wp-block-list">
<li><p>認可サーバ：アクセストークンを発行し、クライアントの認証を行う。</p></li>
<li><p>クライアント：アクセストークンを取得し、リソースサーバへ提示するアプリ。</p></li>
<li><p>リソースサーバ：アクセストークンの妥当性を検証し、保護されたリソースを提供する。</p></li>
</ul>
style_prompt本記事はGeminiの出力をプロンプト工学で整理した業務ドラフト（未検証） です。
令和5年度 秋期 情報処理安全確保支援士 午前Ⅱ 問5 OAuth 2.0
OAuth 2.0においてリソース所有者の権限をアプリに委譲する際に使用される、アクセストークンの性質と発行プロセスを解説します。
OAuth 2.0において，認可サーバがアクセストークンを発行し，クライアントがそのアクセストークンを利用してリソースサーバからリソースを取得する手順はどれか。
ア 認可サーバがリソースサーバにアクセストークンを送信し，リソースサーバがクライアントにそのアクセストークンを送信する。
イ クライアントが認可サーバにアクセストークンの発行を要求し，認可サーバがクライアントにアクセストークンを送信する。
ウ クライアントがリソースサーバに認可コードを送信し，リソースサーバが認可サーバからアクセストークンを取得する。
エ リソースサーバが認可サーバにアクセストークンの発行を要求し，認可サーバがクライアントにアクセストークンを送信する。
【解説】
OAuth 2.0は、サードパーティ製のアプリケーション（クライアント）が、ユーザ（リソース所有者）に代わってHTTPサービス上のリソースへアクセスできるようにする認可フレームワークです。
基本的な「認可コードグラント」のフローにおいて、アクセストークンの発行と利用は以下の流れで行われます。
クライアントがユーザから認可を得て「認可コード」を取得する。
クライアントが認可サーバに対して認可コードを提示し、アクセストークンの発行を要求 する。
認可サーバがクライアントに対してアクセストークンを発行（送信） する。
クライアントがそのアクセストークンをリソースサーバに提示 してリソースを取得する。
sequenceDiagram
participant C as Client
participant "A as Authorization Server"
participant "R as Resource Server"
C ->> A: Request Access Token (with Auth Code)
A -->> C: Issue Access Token
C ->> R: Access Resource (with Access Token)
R -->> C: Protected Resource
【選択肢の吟味】
選択肢
判定
解説
ア
×
アクセストークンは認可サーバからクライアントへ直接渡されます。リソースサーバを経由することはありません。
イ
〇 正解。クライアントが認可サーバに要求し、認可サーバがクライアントへトークンを返却するのが正しい手順です。
ウ
×
認可コードは、クライアントが認可サーバからアクセストークンを取得するために使用する一時的なコードです。
エ
×
トークンの発行を要求する主体はクライアントです。リソースサーバは提示されたトークンを検証する役割を担います。
【ポイント】
認可サーバ：アクセストークンを発行し、クライアントの認証を行う。
クライアント：アクセストークンを取得し、リソースサーバへ提示するアプリ。
リソースサーバ：アクセストークンの妥当性を検証し、保護されたリソースを提供する。
ライセンス ：本記事のテキスト/コードは特記なき限り
CC BY 4.0 です。引用の際は出典URL（本ページ）を明記してください。
利用ポリシー もご参照ください。
コメント