1 認証連携の概要
1.1 目的と利点
1.1.1 利用者体験の向上
認証連携では、利用者が複数のサービスを順に利用する際に、毎回個別のログインを求められる負担を減らす。利用者側では、認証基盤での本人確認が完了した後に、アプリケーション側へ移動しても同一の状態として扱えるため、操作回数が抑えられる。結果として、サービス間での移動が滑らかになり、離脱の要因になりがちな入力作業の集中を避けやすい。
1.1.2 提供側の運用負荷の軽減
提供側は、自組織で認証基盤全体を構築・保守する必要を下げられる。利用者管理、本人確認の導線、認証方式の更新などを認証基盤に集約し、アプリケーションは「受け取った認証結果に基づくアクセス制御」に重点を置ける。統合後は、対応ブラウザや端末、認証フローの差異などの複雑さも基盤側に寄せられるため、サービス群の規模拡大に対して運用設計を再利用しやすい。
1.1.3 セキュリティの一貫性
認証基盤で統一的に対策を適用することで、サービスごとの実装差による抜けを減らす狙いがある。たとえば、なりすまし対策、セッションの取り扱い、署名検証や検証失敗時の扱いなどの共通論点を、同じ設計原則で運用できる。アプリケーション側は認証結果の検証と許可判定に集中でき、セキュリティのばらつきを抑えやすい。
1.2 用語と構成要素
1.2.1 利用者（エンドユーザー）
利用者は、認証基盤において本人確認を受ける主体である。認証連携では、利用者が提示する手続き（認証情報の入力、同意の確認など）が起点となる。アプリケーション側から見れば、認証基盤により確立された「識別」や「アクセス可能性」に基づいて扱われる対象となる。
1.2.2 認証基盤（アイデンティティプロバイダ）
認証基盤は、本人確認と認証結果の発行を担当する。利用者がログインに成功すると、認証基盤は署名付きのトークン、あるいは同等の認証結果を用いて、アプリケーションへ引き渡すための情報を生成する。さらに、同意に基づく属性（利用者に関する情報）の提供範囲を管理し、運用上のポリシーもここで統一される。
1.2.3 アプリケーション（サービスプロバイダ）
アプリケーションは、利用者の認証結果を受け取り、アクセス制御を行う側である。認証連携の実装では、受領した情報が正しい発行元から来たものであること、改ざんされていないこと、有効な期間内であることなどを検証する。その後、利用者に対して必要な許可を判断し、アカウント紐付けや画面表示を行う。
1.2.4 トークン・セッション・属性
トークンは、認証基盤が発行する検証可能な情報であり、利用者の識別や権限の手がかりを含み得る。セッションは、アプリケーション側での利用者状態を示し、後続リクエストでの継続アクセスを可能にする仕組みである。属性は、同意やポリシーに従って共有される利用者の情報（例：利用者の表示名や識別子）を指す。設計では、属性の最小化と、セッションとトークンの役割分担が重要になる。