Question 1

認証連携(フェデレーション)における「IdP(アイデンティティプロバイダ)」と「SP(サービスプロバイダ)」の役割分担の説明として、最も適切なものはどれか。

Accepted Answer

IdPが利用者を認証し、その結果を示す情報をSPへ渡すことで、SPが利用可否を判断する仕組みである。。【解説】認証連携(フェデレーション)の枠組みでは、実際に利用者のID・パスワードや生体情報などを用いて本人確認を行う役割をIdP(アイデンティティプロバイダ)が担う。IdPは認証が済んだことを示す情報(SAMLのアサーションやOIDCのIDトークンなど)をSP(サービスプロバイダ)へ渡し、SPはその情報を検証したうえで自らが提供するサービスへのアクセス可否を判断する。この役割分担により、SP側は自ら認証機能を持たなくても安全にログイン処理を利用者へ提供できる。【他の選択肢が不適切な理由】SPが認証を行いIdPがサービスを提供するという説明は、両者の役割が実際とは逆転しており誤りである。IdPとSPは必ずしも同一組織内に設置する必要はなく、契約関係にある社外の事業者間で認証連携を組む構成も広く行われている。認証連携では、IdPで認証済みであることを示す情報だけがSPへ渡され、利用者のパスワードそのものをSPへ転送して都度照合するような設計にはしない。

Question 2

SAMLを用いたWebブラウザ経由のシングルサインオンにおける処理の流れの説明として、最も適切なものはどれか。

Accepted Answer

IdPが利用者を認証した後、署名付きアサーションを作成し、ブラウザ経由でSPへ送る流れである。。【解説】SAMLによるWebブラウザ経由のシングルサインオンでは、未認証の利用者がSPへアクセスするとIdPへリダイレクトされ、そこで認証を受ける。認証に成功するとIdPは、いつ誰を認証したかといった情報を含むXML形式のアサーションを作成してデジタル署名を付与し、利用者のブラウザを経由してSPへ送信する。SPは受け取った署名を検証し、正当なIdPが発行したものであることを確認したうえで利用者にサービスへのアクセスを許可する。【他の選択肢が不適切な理由】SAMLの仕組みでは利用者のパスワードそのものをSPへ送ることはなく、パスワードの照合はIdP側のみで完結する。利用者の端末とSPが直接に鍵ペアを交換し合う手順もSAMLの標準的な流れではない。SPがIdPのデータベースへ直接アクセスしてパスワードを取得する設計は、認証情報をIdP内に閉じ込めるという認証連携の基本的な考え方に反しており実際には行われない。

Question 3

OAuth 2.0の主な目的として、最も適切なものはどれか。

Accepted Answer

リソースオーナーが自身のパスワードを渡さずに、限られた操作権限だけを委譲できるようにすること。【解説】OAuth 2.0は「認可(Authorization)」の委譲を目的とした仕組みであり、リソースオーナー(利用者)が自身のIDとパスワードを第三者アプリ(クライアント)へ直接渡すことなく、必要最小限の範囲(スコープ)に限定した操作権限だけを、認可サーバーが発行するアクセストークンを介して安全に委譲できるようにする。パスワードを共有しないため、第三者アプリ側での漏えいや過剰な権限付与のリスクを避けられる。【他の選択肢が不適切な理由】デジタル証明書の発行は認証局(CA)の役割であり、OAuth 2.0が担う機能ではない。通信経路上のデータそのものの暗号化はTLS等の役割であり、OAuth 2.0は権限委譲の枠組みであって通信の暗号化技術ではない。複数サーバーへの負荷分散はロードバランサ等の役割であり、認可の委譲を目的とするOAuth 2.0とは無関係である。

Question 4

OAuth 2.0において、認可サーバーが発行し、クライアント(第三者アプリ)がリソースサーバーへAPIアクセスする際に提示する情報はどれか。

Accepted Answer

アクセストークン。【解説】OAuth 2.0では、認可サーバーが利用者の許可(認可)を受けてアクセストークンを発行し、クライアント(第三者アプリ)はこのアクセストークンをリソースサーバーへのAPIリクエストに添えて提示することで、許可された範囲の操作を行うことができる。アクセストークンには有効期限や許可された操作範囲(スコープ)の情報が対応付けられている。【他の選択肢が不適切な理由】IDトークンはOpenID Connectで発行される、利用者の認証結果を示す情報であり、リソースサーバーへのAPIアクセスに使うものではない。秘密鍵は公開鍵暗号方式やデジタル署名で用いる鍵情報であり、認可サーバーがAPIアクセスのために発行するものではない。デジタル証明書は認証局が公開鍵と身元情報を結び付けて発行するものであり、OAuth 2.0のAPIアクセス制御で使う情報とは異なる。

Question 5

OpenID Connect(OIDC)とOAuth 2.0の関係についての説明として、最も適切なものはどれか。

Accepted Answer

OAuth 2.0の認可の仕組みの上に、認証情報を示すIDトークンを追加した拡張仕様がOIDCである。。【解説】OpenID Connect(OIDC)は、OAuth 2.0が持つ「認可」の枠組み(アクセストークンの発行手順)の上に、利用者が確かに認証されたことを示すIDトークンという仕組みを追加した拡張仕様である。OAuth 2.0単体では「どの範囲の操作を許可するか」は扱えても「誰が認証されたか」を標準化された形で伝える手段がなかったため、OIDCがこの認証レイヤーを補っている。【他の選択肢が不適切な理由】OIDCはOAuth 2.0を土台として設計されており、両者は密接に関連する規格であって無関係ではない。API権限の委譲を担うのはOAuth 2.0側であり、利用者の本人確認(認証)を担うのはOIDC側であるため、役割の説明が入れ替わっている。OAuth 2.0はOIDCより先に策定された基盤の規格であり、OIDCの下位互換や制限版という関係ではない。

Question 6

OpenID ConnectにおけるIDトークンに関する説明として、最も適切なものはどれか。

Accepted Answer

JWT形式で発行され、認証日時や対象者など本人性に関する情報(クレーム)を含むものである。。【解説】OpenID ConnectにおけるIDトークンは、JSON Web Token(JWT)形式で発行され、認証が行われた日時、認証対象の利用者を示す識別子(サブジェクト)、発行者、有効期限といった、利用者が確かに認証されたことを示す情報(クレーム)を含んでいる。クライアントはIDトークンの署名を検証することで、正当なIdPによって発行された認証結果であることを確認できる。【他の選択肢が不適切な理由】APIアクセス権限を表しリソースサーバーへの操作範囲を示すのはアクセストークンの役割であり、IDトークンの役割ではない。IDトークンは利用者が任意に設定する暗号鍵ではなく、認証結果を示す情報を格納したトークンである。ロードバランサーが発行する識別子という説明も、認証結果を示すIDトークンの性質とは無関係である。

Question 7

RADIUSプロトコルが企業のネットワーク機器に対して提供する機能の組み合わせとして、最も適切なものはどれか。

Accepted Answer

認証・認可・アカウンティング(利用記録)という、いわゆるAAAの機能の組み合わせ。【解説】RADIUS(Remote Authentication Dial In User Service)は、無線LANのアクセスポイントやVPN装置などのネットワーク機器に代わって、利用者が正当な利用者かを確認する認証(Authentication)、その利用者にどこまでの操作や接続を許可するかを決める認可(Authorization)、接続時間や通信量などの利用状況を記録するアカウンティング(Accounting)という3つの機能を提供する、いわゆるAAAサーバーとしての役割を担う。【他の選択肢が不適切な理由】経路制御やアドレス変換、パケットフィルタリングはルーターやファイアウォールが担うネットワーク制御の機能であり、RADIUSの役割ではない。圧縮や誤り訂正、再送制御は通信品質を確保するための技術であり、利用者認証を担うRADIUSの機能とは異なる。負荷分散や冗長化、自動フェイルオーバーは可用性を高めるための仕組みであり、認証・認可・利用記録を扱うRADIUSの機能の説明としては誤りである。

Question 8

企業無線LANのIEEE802.1X認証において、接続を要求する利用者端末(サプリカント)や中継を行うアクセスポイント(オーセンティケータ)からの問い合わせを受け、実際にID・パスワードや証明書を検証して認証の可否を判定するサーバーはどれか。

Accepted Answer

RADIUSサーバー。【解説】IEEE802.1X認証は、接続を要求する利用者端末である「サプリカント」、通信を中継する「オーセンティケータ」(無線LANアクセスポイントやスイッチ)、そして実際に認証情報を検証し可否を判定する「認証サーバー」の3者で構成される。この認証サーバーの役割を担うのが一般にRADIUSサーバーであり、オーセンティケータから転送された認証情報を検証し、結果をオーセンティケータへ通知することで通信の許可・拒否を制御する。【他の選択肢が不適切な理由】DNSサーバーはドメイン名とIPアドレスの対応付けを行うサーバーであり、認証情報の検証は行わない。NTPサーバーは機器同士の時刻を同期するためのサーバーであり、802.1X認証の可否判定とは無関係である。DHCPサーバーは端末へIPアドレス等のネットワーク設定を割り当てるサーバーであり、ID・パスワードや証明書の検証を行う役割ではない。

Question 9

企業が認証連携(SSO)を導入することで得られる利用者側・管理者側双方のメリットとして、最も適切なものはどれか。

Accepted Answer

利用者はサービスごとのパスワードを覚える必要が減り、管理者はアカウントを一元管理しやすくなる。。【解説】認証連携(SSO)を導入すると、利用者は一度IdPで認証を受ければ連携している複数のサービスを個別のログインなしに利用できるため、サービスごとに異なるパスワードを記憶し使い分ける負担が軽減され、結果としてパスワードの使い回しに起因する漏えいリスクの低減にもつながる。管理者側も、退職者のアカウント無効化などをIdP側で一元的に行えるようになり、各サービス個別にアカウントを管理する手間を減らせる。【他の選択肢が不適切な理由】SSOは認証の手間を一度にまとめる仕組みであり、認証そのものが不要になったり誰でも無条件にログインできたりするわけではない。利用者データが自動的に一つのデータベースへ統合されるわけではなく、各サービスは引き続き自らのデータを個別に管理する。SSOは認証手続きに関する仕組みであり、通信経路上の盗聴・改ざん対策はTLS等の別の技術が担うため、導入だけでこれらのリスクが消滅するわけではない。

Question 10

認証連携(SSO)を導入する際に注意すべき点として、最も適切なものはどれか。

Accepted Answer

IdPが乗っ取られると、連携する全SPへ不正ログインが広がるため、保護を特に強化する必要がある。。【解説】認証連携(SSO)では複数のSPがIdPによる認証結果を信頼する構成になるため、もしIdPが攻撃を受けて利用者アカウントを乗っ取られると、その1つのアカウントを起点に連携している全てのSPへ不正にログインされる被害が同時に広がるおそれがある。そのためIdP自体には多要素認証の導入や不正アクセス監視の強化など、他のシステム以上に手厚い保護対策を講じる必要がある。【他の選択肢が不適切な理由】SSOはパスワードを一元化する仕組みであり、不正アクセスの可能性を技術的にゼロにするものではなく、むしろIdPが突破された際の影響範囲は大きくなる。SSOでもIdPとSPの間でアサーションやトークンをやり取りする通信は発生するため、盗聴対策の検討が不要になるわけではない。利用者はIdPへログインする際に依然としてパスワード等の認証情報を設定・管理する必要があり、パスワード管理が一切不要になるわけではない。

認証連携技術(SSO・SAML・OAuth・RADIUS)の一問一答