令和3年度 春期 情報処理安全確保支援士試験 午後Ⅰ 問題 問1 OAuthを用いたSaaSのID連携と多要素認証の導入に伴う権限の最小化と脆弱性対策
テクノロジセキュリティ技術
学習ガイド
ファイル共有サービスの認証方式を多要素認証にするため、外部SNSとのID連携を導入する事例です。OAuthの認可シーケンスの仕組みと、連携に伴うセキュリティ上の課題について問われます。まず認可に関わる主体の役割とやり取りを整理し、次に攻撃シーケンスの図から罠サイトを通じた不正なファイル操作の手口を読み解きます。最後に、外部サービスに依存することによる可用性の低下リスクや権限の最小化といった、安全な設計に必要な観点を確認します。
この記事で押さえる論点
- OAuthのAuthorization Code Grantにおける認可のシーケンスと各主体の役割を説明できる
- stateパラメタを用いてCSRF（罠サイトによるセッション乗っ取り）を防ぐ仕組みを説明できる
- 認可要求において、利用する機能に限定して必要最小限の権限を要求する理由を述べられる
- 外部サービスとの連携時に可用性が低下するリスクと、障害発生時の代替となる認証手段を説明できる
出題情報
- 出題
- 2021(R3)春 情報処理安全確保支援士 午後I 問1
- 配点
- 50点満点
- 模範解答
- 公表(設問ごとに掲載)
出題趣旨・採点講評(IPA 公表)
昨今，ソーシャルログインが普及してきており，その中でもOAuthを用いたものは様々なWebサービスで利用されている。Webサービスにおける認証機能の開発において，OAuthを理解し，セキュリティ上の考慮点を踏まえた設計を行うことが欠かせないものとなってきている。
本問では，認証システムの開発を題材に，OAuthを用いたソーシャルログインの実装，及びそのセキュリティに関する理解力を問う。
問1では，認証システムの開発を題材に，OAuthを用いたソーシャルログインシステムの実装，及びそのセキュリティについて出題した。全体として正答率は平均的であった。
問題本文
問1 認証システムの開発に関する次の記述を読んで，設問1〜4に答えよ。
S社は，従業員 10 名のベンチャー企業である。S社のファイル共有サービス（以下，Sサービスという）は機能が豊富であり，登録会員（以下，S会員という）の数を伸ばしている。
Sサービスでは，利用者認証されたS会員が写真などのファイルを自身に割り当てられたフォルダにアップロードできる。さらに，当該ファイルにアクセスするためのURLを電子メールなどで他者に示すことによって，当該ファイルを他者と共有できる。また，Sサービス内でメッセージや“いいね”を送信できる。
Sサービスの企画，開発及び運用は，CTOのF氏が取り仕切っており，そのうち，開発と運用は，F氏の指示の下，S社エンジニア 2 名が行っている。Sサービスは，外部セキュリティ企業による脆弱性診断を随時受けている。
〔Sサービスの改修〕
前回の脆弱性診断では，利用者IDとパスワードを用いて利用者認証するSサービスの認証モジュール（以下，S認証モジュールという）の認証方式を，多要素認証にする方がよいとのアドバイスを受けたが，その対処が課題であった。そこで，F氏は，認証及び認可を提供するSNS（以下，認証認可提供SNSという）のうち，多要素認証などの機能をもつT社のTサービスとSサービスとをID連携する改修をCEOのX氏に提案した。その改修によって，S認証モジュールを用いないS会員の登録と多要素認証の実現を目指す。ただし，今回の改修でのID連携では，既存のS会員は対象とせず，新規登録のS会員だけを対象とする。改修後も当面は既存のS会員の認証のために，S認証モジュールも継続して稼働させる。
F氏は，①S認証モジュールの代わりにTサービスとのID連携を利用することにはどのような利点と欠点があるかをX氏に説明した。X氏は，ID連携技術に詳しい情報処理安全確保支援士（登録セキスペ）のY氏を外部から招聘して，実装の最終段階でのレビューを受けることを前提に，Sサービスの改修を承認した。
今回の改修では，OAuthのAuthorization Code Grantを採用する。OAuthは，認証認可提供SNSと認可情報を送受信するためのプロトコルの一つである。OAuthを用いた認可における三つの主体の説明を図1に，認可のシーケンスを図2に示す。
図の説明テキスト
| 主体 | 説明 |
|---|---|
| 利用者 | Tサービスのアカウントをもち, S会員の登録を希望する者(以下, S会員登録希望者という)及び登録されたS会員である。 |
| Sサービス | Tサービスでのアカウント名を要求する。 |
| Tサービス | 認証認可提供SNSである。図3に示す権限を提供する。 |
注記 Tサービスのアカウント名は変更できない。
図1 OAuthを用いた認可における三つの主体の説明
図の説明テキスト
OAuthを用いた認可のシーケンス。
参加者: 利用者, Sサービス, Tサービス
- 利用者 -> Sサービス: (あ) 利用開始
- Sサービス -> 利用者: (い) 認可の要求
- リダイレクト: 利用者 -> Tサービス: (う) 認可の要求
- 利用者 <-> Tサービス(双方向): (え) 認証，権限付与の確認
- Tサービス -> 利用者: (お) 認可コード
- リダイレクト: 利用者 -> Sサービス: (か) 認可コード
- Sサービス -> Tサービス: (き) アクセストークンの要求
- Tサービス -> Sサービス: (く) アクセストークン
- Sサービス -> Tサービス: (け) アカウント名の要求
- Tサービス -> Sサービス: (こ) アカウント名
注記 Sサービスは，S会員登録希望者による利用の初回に，S会員登録希望者がログイン中のTサービスから取得したアカウント名(以下，T-IDという)をSサービス内に登録する。Tサービスにログインしていない場合はログインが促される。2回目以降のSサービスの利用の場合，初回に登録されたT-IDを確認する。
図2 OAuthを用いた認可のシーケンス
図の説明テキスト
| 記号 | 権限 |
|---|---|
| (ア) | 他の利用者の投稿に対し“いいね”を送信する権限 |
| (イ) | 他の利用者へのメッセージを送信する権限 |
| (ウ) | 利用者の代わりに投稿する権限 |
| (エ) | 利用者のアカウント名，電子メールアドレスなど登録情報を取得する権限 |
図3 Tサービスが提供する権限
図2のシーケンスにおいて，aは，bが提供するリソースにアクセスできる。それはcが，図3に示す権限をaに与えるからである。cはaに与える権限を図2中のαの通信の際に確認する。図3のうち，どの権限を要求するかは，aの実装者が決定する。S社では，要求した権限のいずれか一つでも，cが与えることを拒否する場合は，シーケンスを止めるように実装することにした。
なお，Sサービスでは，将来どの権限も利用すると考え，図3の全権限を要求することにした。
次に，TサービスとSサービスとのID連携について，実装の最終段階でY氏のレビューを受けた。Y氏はセキュリティ上の問題を三つ指摘した。
〔一つ目の問題〕
Y氏は，一つ目の問題を，次の攻撃シナリオで説明した。
Sサービスにログインしていない利用者が攻撃者の用意した罠サイトにアクセスすると，図4中に示すシーケンスXが走り，後に，②利用者が攻撃を受けているとは知らずにSサービスにファイルをアップロードすると，そのファイルを攻撃者にダウンロードされてしまうおそれがある。
図の説明テキスト
図4 攻撃のシーケンス
参加ノード: 利用者、攻撃者、S サービス、T サービス
シーケンスの流れ:
- 利用者から攻撃者へ: 罠サイトへのアクセス
【以下の手順2〜7は、右側に「シーケンス X」という波括弧でまとめられている】 - 攻撃者からS サービスへ: 利用開始
- S サービスから攻撃者へ: 認可の要求
- 攻撃者での処理: リダイレクト（S サービスからの応答を受けて、T サービスへリダイレクトする曲線の矢印）
- 攻撃者からT サービスへ: 認可の要求
- 攻撃者とT サービス間: 認証, 権限付与の確認
- T サービスから攻撃者へ: 認可コード
【シーケンス X ここまで】 - 攻撃者から利用者へ: 四角枠のdを含む応答
- 利用者での処理: リダイレクト（攻撃者からの応答を受けて、S サービスへリダイレクトする曲線の矢印）
- 利用者からS サービスへ: 四角枠のdを含む要求
- S サービスからT サービスへ: 四角枠のeを含む要求
- T サービスからS サービスへ: アクセストークン
（波線による省略・中断） - 利用者からS サービスへ: ファイルのアップロード
この対策として，RFC 6749は，図2のシーケンスで，推測困難な値であるstateパラメタを利用することを推奨している。Sサービスはstateパラメタをβを送信する際に付与する。Sサービスはγを受信する際に，そのセッションが，stateパラメタを付与した際のβのセッションと同一であるか否かを確認する。同一である場合だけシーケンスを続ける。
〔二つ目と三つ目の問題〕
二つ目の問題は，③SサービスがTサービスに要求する権限が必要最小限のものになっていないことである。この問題については，要求する権限を一つだけにした。
三つ目の問題は，Tサービスに深刻な脆弱性が報告された場合の対応方法を決めていなかったことである。この問題については，TサービスとのID連携を一時的に停止し，S認証モジュールだけで認証することにした。ただし，このとき④一部のS会員はSサービスを利用できなくなるので，対象のS会員向けに代替策を検討することにした。
〔利用者認証の実現について〕
X氏は，全面改修してS認証モジュールを停止した後の利用者認証の実現方式についてY氏に確認した。Sサービスは利用者を直接認証していないが，⑤Sサービスは，登録されたS会員をどのように利用者認証しているかを，Y氏はX氏に解説した。
S社では，Y氏から指摘された問題を解決した後，TサービスとSサービスとのID連携を開始した。
設問と解答・解説
設問1
〔Sサービスの改修〕について，(1)〜(4)に答えよ。
本文中の下線①について，S社の課題に即した利点を30字以内で具体的に述べよ。
模範解答
多要素認証の実装をSサービス側に用意しなくてよい。
採点基準
- 3点: 多要素認証の機能を提供できることを適切に示している。
- 1点: 多要素認証の観点に触れているが、記述が不十分である。
- 0点: 多要素認証に関する適切な記述がない。
- 2点: Sサービス側で実装・用意する必要がない（肩代わりされる）という構造が明確に記述されている。
- 0点: Sサービス側での実装が不要になるという構造が記述されていない。
解説
- 課題文の〔Sサービスの改修〕の段落において、Sサービスの課題として「前回の脆弱性診断では，利用者IDとパスワードを用いて利用者認証するSサービスの認証モジュール（以下，S認証モジュールという）の認証方式を，多要素認証にする方がよいとのアドバイスを受けたが，その対処が課題であった。」と記載されている。
- それに対する解決策として、F氏は「多要素認証などの機能をもつT社のTサービスとSサービスとをID連携する改修」を提案している。
- 「その改修によって，S認証モジュールを用いないS会員の登録と多要素認証の実現を目指す。」とある通り、Tサービスに認証を委ねることで、Sサービス自身で多要素認証の仕組みを開発・実装する手間を省けることが、S社の課題に即した利点となる。
高得点のポイント
- 課題であった「多要素認証」の機能を提供できることを示していること。
- 外部SNSとの連携により、Sサービス側で多要素認証の実装や仕組みを自前で用意する必要がない（肩代わりされる）という構造が明確に記述されていること。
本文中の下線①について，可用性の観点での欠点を30字以内で述べよ。
模範解答
Tサービスの障害時にSサービスを利用できない。
採点基準
- 3点: Tサービス側での障害やサービス停止に言及している。
- 1点: Tサービス側の問題に触れているが、可用性の観点として不十分である。
- 0点: 可用性に関する適切な記述がない。
- 2点: その結果としてSサービスが利用できなくなることが論理的に繋がって記述されている。
- 0点: Sサービスへの影響について明確に記述されていない。
解説
- ID連携（OAuth）を利用する場合、利用者認証の処理を外部のTサービスに依存することになる。
- したがって、可用性（システムが継続して稼働し続けられる性質）の観点では、Sサービス自体が正常に稼働していても、依存先であるTサービスにおいてシステム障害が発生したりサービスが停止したりすると、利用者は認証を行うことができず、結果としてSサービスを利用できなくなるという欠点が生じる。
高得点のポイント
- Tサービス側での障害やサービス停止に関する言及があること。
- その結果としてSサービス（の認証）が利用できなくなることが論理的に繋がって記述されていること。
本文中の a に入れる適切な字句を解答群の中から選び，記号で答えよ。
模範解答
選択肢ア: Sサービス
解説
- 図1 OAuthを用いた認可における三つの主体の説明 と 図2 OAuthを用いた認可のシーケンス を基に判断する。
- 問題文に「は，が提供するリソースにアクセスできる。」とある。
- 図2のシーケンスでは、(き)で「アクセストークンの要求」を行い、(く)で「アクセストークン」を取得し、それを用いて(け)で「アカウント名の要求」というリソースアクセスを行っているのは Sサービス である。したがって、リソースにアクセスする主体である は Sサービス になる。
各選択肢の解説
- ア: 正解。
- イ: Tサービスはリソースを提供する側（）であり、アクセスする主体ではないため誤り。
- ウ: 利用者は権限を与える主体（）であり、リソースに直接アクセスしてアカウント名を要求するシステムではないため誤り。
本文中の b に入れる適切な字句を解答群の中から選び，記号で答えよ。
模範解答
選択肢イ: Tサービス
解説
- 問題文に「が提供するリソース」とある。
- 図1 OAuthを用いた認可における三つの主体の説明 において、Tサービス は「認証認可提供SNSである。図3に示す権限を提供する。」と記載されている。
- つまり、権限（リソース）を提供している主体である は Tサービス になる。
各選択肢の解説
- ア: Sサービスはリソースにアクセスする主体（）であり、リソースを提供する側ではないため誤り。
- イ: 正解。
- ウ: 利用者は権限を与える主体（）であり、リソースを提供するシステムではないため誤り。
本文中の c に入れる適切な字句を解答群の中から選び，記号で答えよ。
模範解答
選択肢ウ: 利用者
解説
- 問題文に「それはが，図3に示す権限をに与えるからである。」とある。
- 図2 OAuthを用いた認可のシーケンス において、(え)「認証，権限付与の確認」を行っているのは、Tサービスと 利用者 の間である。
- システム間の連携において、自分の情報の利用権限をSサービスに与える許可を出す主体は利用者自身であるため、 は 利用者 になる。
各選択肢の解説
- ア: Sサービスは権限を与えられる側（）であるため誤り。
- イ: Tサービスは権限付与の確認をユーザーに求める側であり、自身の権限を与える主体ではないため誤り。
- ウ: 正解。
本文中の α に入れる適切な字句を，図2中の(あ)〜(こ)から選び，記号で答えよ。
模範解答
選択肢エ: (え) 認証，権限付与の確認
解説
- 問題文に「（利用者）は（Sサービス）に与える権限を図2中の の通信の際に確認する。」とある。
- 図2 OAuthを用いた認可のシーケンス を見ると、利用者とTサービスの間で行われる双方向の通信として、(え) 認証，権限付与の確認 が存在する。
- ここで利用者は、Sサービスに対してTサービス上のリソース（図3に示す権限）を許可するかどうかを判断・確認する。
各選択肢の解説
- ア (あ) 利用開始: 利用者がSサービスにアクセスする最初のトリガーであり、権限の確認はまだ行われないため誤り。
- イ (い) 認可の要求: Sサービスが利用者のブラウザに対してTサービスへのリダイレクトを指示する応答であり、利用者が権限を確認する段階ではないため誤り。
- ウ (う) 認可の要求: 利用者のブラウザがTサービスにアクセスする要求であり、権限の確認画面を表示するための要求に過ぎないため誤り。
- エ (え) 認証，権限付与の確認: 正解。
- オ (お) 認可コード 〜 コ (こ) アカウント名: これらは権限が付与された後にシステム間でトークンや情報をやり取りする通信であり、利用者が権限を確認するステップではないため誤り。
設問1(2)は，正答率が平均的であった。認証を行うSNSと連携する場合における可用性の観点での欠点を問うたが，SNSと連携しない場合にも該当する欠点について記述した解答が散見された。題意をよく読んで解答してほしい。 設問1(3)は，正答率が低かった。OAuthがどのように使われているかを問うたが，仕組みを理解していない解答が多かった。OAuthのプロトコルをよく理解しておくとともに，図のシーケンスから仕組みを正確に読み取ることにも注力してほしい。
設問2
〔一つ目の問題〕について，(1)〜(3)に答えよ。
図4中の d に入れる適切な字句を解答群の中から選び，記号で答えよ。
模範解答
選択肢ウ: 認可コード
解説
- 図4 攻撃のシーケンス の流れを読み解く。
- シーケンスXにおいて、攻撃者はTサービスと通信し、自身のTサービスアカウントに対する認可コード（シーケンスXの最後に Tサービスから攻撃者へ返るもの）を取得している。
- その後、攻撃者は罠サイトにアクセスした利用者のブラウザに対して、「四角枠の [d] を含む応答」を返し、Sサービスへリダイレクトさせている。
- OAuthの仕様上、リダイレクトを通じてSサービスに渡されるパラメタは、Tサービスが発行した 認可コード である。
- [d] は図4の攻撃者から利用者への応答と、リダイレクトによる利用者からSサービスへの要求の2か所にあり、図2の (お) 及び (か) に相当する。
- したがって、パラメタ [d] は、認可コード となる。
各選択肢の解説
- ア アクセストークンの要求: SサービスがTサービスに送る要求の名称であり、利用者のブラウザを経由して送られるパラメタではないため誤り。
- イ アクセストークン: 認可コードと引き換えに後からTサービスがSサービスに直接発行するものであり、利用者のブラウザを経由しないため誤り。
- ウ: 正解。
- エ 認可の要求: 認証を開始するための要求であり、リダイレクト時にTサービスから付与される値ではないため誤り。
- オ 認証，権限付与の確認: 利用者とTサービス間で行われる画面上のやり取りであり、パラメタ名ではないため誤り。
図4中の e に入れる適切な字句を解答群の中から選び，記号で答えよ。
模範解答
選択肢ア: アクセストークンの要求
解説
- 図4 攻撃のシーケンス の利用者から [d] を受け取った Sサービスが Tサービスへ送る要求(四角枠 [e])において、Sサービスは認可コードを用いてTサービスへ通信を行っている。
- 図2の正常なシーケンスを参照すると、Sサービスが認可コードを受け取った後にTサービスに対して行う通信は (き) アクセストークンの要求 である。
- 図4の画像において、このSサービスからTサービスへの要求の矢印には「四角枠の [e]」というラベルが付与されているため、[e] にはこの通信の名称である「アクセストークンの要求」が入る。
各選択肢の解説
- ア: 正解。
- イ アクセストークン: この要求に対するTサービスからの応答（図4の次のステップ）の名称であるため誤り。
- ウ 認可コード: Sサービスが送る要求に含まれる「パラメタ」であるが、図2の(き)に相当する通信全体の名称としては「アクセストークンの要求」が適切であるため誤り。
- エ 認可の要求: 認証シーケンスの初期段階で行う要求であり、認可コード取得後の通信ではないため誤り。
- オ 認証，権限付与の確認: 利用者とTサービス間のやり取りであり、SサービスとTサービス間のシステム通信ではないため誤り。
本文中の下線②について，ファイルのアップロードは，Tサービスの誰のアカウントによって行われるか。6字以内で答えよ。
模範解答
攻撃者
採点基準
- 3点: 「攻撃者」と解答している（攻撃者のアカウント、攻撃者のIDなど同義可）。
- 1点: 攻撃者を指しているが不明確である（「第三者」「悪意のある者」など）。
- 0点: 「利用者」「被害者」「S会員」など誤った対象、またはそれ以外。
- 2点: 誰のアカウントかを名詞で明確に答えている（攻撃者を指す場合に限る）。
- 0点: 利用者など誤った対象、または対象が不明確である。
解説
- 攻撃のシーケンス（図4）において、Sサービスが取得した認可コード（）は、シーケンスXによって攻撃者が自身のTサービスアカウントで認証して得たものである。
- したがって、Sサービスがその認可コードを用いてTサービスから取得するアクセストークン及び T-ID は、攻撃者 のものとなる。
- 図2の注記に「S会員登録希望者がログイン中のTサービスから取得したアカウント名(以下，T-IDという)をSサービス内に登録する」とある通り、Sサービスは罠サイトを踏んだ利用者の現在のセッションを、取得した攻撃者のT-IDと紐付ける。
- この状態で利用者がSサービスにファイルをアップロードすると、Sサービス内では現在セッションに紐付いている 攻撃者 のアカウントにファイルが割り当てられる。
高得点のポイント
- CSRF攻撃（ログインCSRF）のメカニズム上、セッションが攻撃者のアカウントに紐付くことを正しく理解できていること。
- 「攻撃者」という対象を明確に回答していること。
本文中の下線②について，ファイルのダウンロードは，Tサービスの誰のアカウントによって行われるか。6字以内で答えよ。
模範解答
攻撃者
採点基準
- 3点: 「攻撃者」と解答している（攻撃者のアカウント、攻撃者のIDなど同義可）。
- 1点: 攻撃者を指しているが不明確である（「第三者」「悪意のある者」など）。
- 0点: 「利用者」「被害者」など誤った対象、またはそれ以外。
- 2点: 誰のアカウントかを名詞で明確に答えている（攻撃者を指す場合に限る）。
- 0点: 誤った対象、または対象が不明確である。
解説
- 前問の通り、利用者がアップロードしたファイルは、Sサービス内において 攻撃者 のT-IDに紐付いて保存される。
- したがって、攻撃者が自身のTサービスアカウントを用いてSサービスに正常にログインすると、当該ファイルは自身に割り当てられたフォルダ内に存在することになる。
- その結果、ファイルを閲覧・ダウンロードできる権限を持つのは 攻撃者 のアカウントとなる。
高得点のポイント
- アップロードされたファイルが攻撃者のアカウントの権限下に配置されることを正しく理解できていること。
- 「攻撃者」という対象を明確に回答していること。
本文中の β に入れる適切な字句を，図2中の（あ）〜（こ）から選び，記号で答えよ。
模範解答
選択肢イ: (い) 認可の要求
解説
- 攻撃対策として導入される stateパラメタ は、リクエストを生成した元のセッションと、コールバックで戻ってきたセッションが同一であることを確認するための推測困難な値である。
- 問題文に「Sサービスはstateパラメタを[ ]を送信する際に付与する。」とある。
- Sサービスが外部（Tサービス）での認証を開始させるために、利用者のブラウザに対してリダイレクトを指示する最初の通信は、図2の (い) 認可の要求 である。ここで生成した推測困難な値を含めて送信する。
各選択肢の解説
- ア (あ) 利用開始: 利用者がSサービスに対して行う操作であり、Sサービスが送信する通信ではないため誤り。
- イ: 正解。
- ウ (う) 認可の要求: 利用者のブラウザがTサービスに対して送信するものであり、Sサービスが送信する主体ではないため誤り。
- エ (え) 認証，権限付与の確認 〜 コ (こ) アカウント名: 全て認証シーケンスの後続のステップであり、最初の要求時に付与するというstateパラメタの要件を満たさないため誤り。
本文中の γ に入れる適切な字句を，図2中の（あ）〜（こ）から選び，記号で答えよ。
模範解答
選択肢カ: (か) 認可コード
解説
- 問題文に「Sサービスは[ ]を受信する際に，そのセッションが，stateパラメタを付与した際の[ ]のセッションと同一であるか否かを確認する。」とある。
- Tサービスは、認証を終えた利用者をSサービスにリダイレクトさせる際、要求時に受け取ったstateパラメタをそのまま付与して返す。
- 図2において、SサービスがTサービスからの結果を利用者のブラウザ経由で受け取るステップは (か) 認可コード である。
- この通信を受信した時点で、Sサービスはパラメタの同一性を検証する。
各選択肢の解説
- ア (あ) 利用開始 〜 オ (お) 認可コード: これらはSサービスが結果を受信する前のステップであるため誤り。
- カ: 正解。
- キ (き) アクセストークンの要求 〜 コ (こ) アカウント名: これらは検証を終えた後に行うサーバー間の直接通信であり、利用者のブラウザ経由でリダイレクト結果を受け取るステップではないため誤り。
設問2(2)は，正答率が低かった。攻撃者が用意したアカウントに利用者が導かれてしまうことを問うたが，利用者のアカウントによって行われると記述した解答が多かった。セキュリティ対策においては攻撃の手口を理解することが必要になるので，シラバスにあるような攻撃の手口を学習してほしい。
設問3
〔二つ目と三つ目の問題〕について，(1)，(2)に答えよ。
本文中の下線③について，必要最小限の権限を図3中の（ア）〜（エ）から一つ選び，記号で答えよ。
模範解答
選択肢エ: (エ) 利用者のアカウント名，電子メールアドレスなど登録情報を取得する権限
解説
- 本文中の〔Sサービスの改修〕の段落に、「その改修によって，S認証モジュールを用いないS会員の登録と多要素認証の実現を目指す。」と記載されている。
- また、図2の注記には「Tサービスから取得したアカウント名(以下，T-IDという)をSサービス内に登録する」とあり、Sサービスが認証のためにTサービスから取得する必要があるのはT-IDの情報のみである。
- Sサービスには自身の機能としてメッセージ送信や“いいね”が存在するが、Tサービス側で利用者に代わってそれらを行う要件はない。
- したがって、図3のうち、認証と登録の実現に必要最小限の権限は (エ) 利用者のアカウント名，電子メールアドレスなど登録情報を取得する権限 のみとなる。
各選択肢の解説
- ア (ア) 他の利用者の投稿に対し“いいね”を送信する権限: Sサービスの認証や登録には不要な権限であるため誤り。
- イ (イ) 他の利用者へのメッセージを送信する権限: 同様に認証や登録には不要であるため誤り。
- ウ (ウ) 利用者の代わりに投稿する権限: 同様に認証や登録には不要であるため誤り。
- エ: 正解。
本文中の下線④に該当するS会員を，35字以内で述べよ。
模範解答
S認証モジュールに利用者IDとパスワードを登録していないS会員
採点基準
- 3点: 対象となるのが「S認証モジュールを利用していない（ID連携のみの）会員」であることを特定できている。
- 1点: 対象会員の特定が不十分である。
- 0点: 対象会員に関する適切な記述がない。
- 3点: 該当するS会員を「S認証モジュールに利用者ID・パスワードを登録していない（=TサービスとのID連携だけで登録した）」という条件で限定した表現になっている（理由・代替手段の記述は不要）。
- 1点: 限定が曖昧である（「新規のS会員」だけ、「一部のS会員」など）。
- 0点: 既存のS会員など誤った対象、または記述がない。
解説
- 問題文の〔Sサービスの改修〕の段落に、「今回の改修でのID連携では，既存のS会員は対象とせず，新規登録のS会員だけを対象とする。」「当面は既存のS会員の認証のために，S認証モジュールも継続して稼働させる。」と記載されている。
- Tサービス連携による改修後に登録した「新規登録のS会員」は、T-IDを用いた認証のみを利用しており、従来の「S認証モジュール」には利用者IDとパスワードを登録していない。
- したがって、TサービスとのID連携を一時的に停止した場合、これら新規のS会員はS認証モジュールでの認証ができないため、Sサービスを利用できなくなる。
高得点のポイント
- 対象となるのが、ID連携のみで登録された「新規会員」であることを正しく特定できていること。
- その会員がSサービスを利用できなくなる理由として、S認証モジュール（ID/パスワード）に登録がないという構造を明示できていること。
設問4
本文中の下線⑤について，Sサービスは，Tサービスと連携して，どのように利用者認証を実現しているか。実現の方法を50字以内で具体的に述べよ。
模範解答
Tサービスで認証されたS会員のT-IDが，Sサービス内に登録されていることを確認する。
採点基準
- 3点: Tサービスから正当なT-IDを取得することに言及している。
- 1点: Tサービスとの連携について触れているが、T-IDの取得が不明確である。
- 0点: Tサービスからの情報取得に関する適切な記述がない。
- 3点: 取得したT-IDがSサービス内に登録済みのものと一致するか照合するプロセスが明確に記述されている。
- 1点: 照合プロセスについての記述が不十分である。
- 0点: 照合プロセスに関する記述がない。
解説
- 図2の注記において、Sサービスは「初回に登録されたT-ID」と、「2回目以降のSサービスの利用の場合」に認証されたT-IDの突き合わせを行っていることが読み取れる。
- Sサービス自体はパスワードを検証しない代わりに、TサービスでのOAuth認証シーケンスを成功させることで、利用者がTサービスの正当なアカウント保有者であることを確認する。
- その上で、Tサービスから返却された T-ID が、Sサービス内にあらかじめ登録されているS会員のT-IDと一致するかを確認することで、自サービスの利用者認証を実現している。
高得点のポイント
- OAuthの仕組み上、Tサービス側で利用者が認証され、T-IDが取得されることに言及していること。
- 取得したT-IDが、Sサービス内にあらかじめ登録されたものと一致することを確認するプロセスを明確に記述していること。