SAML / OAuth2 / OpenID Connect（OIDC）の整理
はじめに
ソフトウェアのセキュリティにおいて、認証・認可の標準規格は複数あります。
いくつか調べたのですが少し複雑なため、自分用に本記事でまとめます。
ちょっと復習：認証 VS 認可
SAMLなどの認証・認可プロトコルの話をする前に、認証・認可について復習しておきましょう。
oktaのドキュメントがわかりやすいです。要約して以下に記載します。
- 認証：本人確認のプロセス。具体的には以下のプロセスで本人確認を行います。
- パスワード
- 認証アプリ
- 生体認証
- 認可：特定のリソース（アプリや機能）にアクセスする許可
- 認証が完了した後に、認可のプロセスを実行するのが安全なプロセス
oktaのドキュメントに、認証・認可の違いを説明した例がわかりやすいため、引用します。
ある家族が休暇で留守の間、その家のペットを世話するために訪れた人が、施錠されたドアの前に立っている状況を考えてみましょう。この人物には、以下が必要です。
・認証:この場合は、家の鍵です。施錠されたドアは、正しい鍵を持つ人だけが開けることができます。これは、システムが正しい資格情報を持つユーザーにのみアクセス権を付与する認証と同じことです。
・認可:この場合は、家に入る許可です。家の中では、キッチンに入り、ペットフードを保管している食器棚を開けることができます。しかし、昼寝のために寝室に入る許可は与えられないでしょう。
SAMLとは
概要
SAMLとは、Security Assertion Markup Languageの略称です。
主に、SSO(シングルサインオン)を実現するために使われる。
認証・認可に関する情報（メインは認証だが、認可に必要な情報を渡すことも可能）をXML形式でやりとりするための標準規格です。
流れ
SAML認証を理解する上で、理解すべきは登場人物です。
主に以下の登場人物が出てきます。
- SP(サービスプロバイダー)：ユーザーがログインしたいアプリケーション（SlackやNotionなど）
- IDP（IDプロバイダー）：主に認証を担当する
- ユーザー：SPを使いたい人を指します。
主な流れは日立ソリューションズ様の記事の図解がわかりやすいため引用いたします。
日立ソリューションズ様の記事引用
OAuth2.0
概要
OAuthは、Open Authorizationの略です。
注意が必要なのは、認可の技術ということです。（認証ではない）
流れ
SAMLと同様に、登場人物をまず押さえます。
- リソースオーナー：保護されたリソースを有するユーザー
- クライアント：保護されたリソースにアクセスするクライアントアプリケーション
- 認可サーバー：認可を担当するサーバー
- リソースサーバー：保護されたリソースを有するサーバー
ちょっとわかりづらいので、具体的なユースケースを考えてみます。
例えば、Googleカレンダーの予定を見て、ユーザーの勉強スケジュールをAIが自動で作成してくれるアプリを考えてみましょう。(以下このアプリを、TODOアプリと表現します。)。このアプリにユーザーのGoogleカレンダーのリソースをアクセスするとき、登場人物は以下の通りです。
- リソースオーナー : リソース=「Googleカレンダーの情報」を指すため、そのオーナーはユーザーになります。
- クライアント：TODOアプリ
- 認可サーバー：GoogleのOAuthサーバー(認可サーバー)
- リソースサーバー : Googleカレンダーのリソースを持っているGoogleのサーバー
OAuth2.0はグラントタイプ（保護されたリソースにアクセスする方法）によって認可プロセスが変わります。一番有名は「認可コードグラント」のフローについて以下記事で丁寧に説明されているため、ご参照ください。
個人的にとてもわかりやすかったのは川崎 貴彦様の図解がとてもわかりやすかったです。
他にも参考にした記事は以下となります。
RFC 6749 の Section 4.1 Authorization Code Grant
OpenID Connect（OIDC）
概要
OIDCはOAuthを拡張仕様です。
OIDCは認証がメインですが、OAuthの認可の要素も含みます。
流れ
OIDCもフローがたくさんあるため、以下の記事で読むことをお勧めします。
OAuthとは異なり、OIDCはIDトークン(=「誰がログインしたか」を証明するためのトークン)を付与します。
最後に
少し駆け足になってしまいましたが、実装も今度やってみたいと思いました。
Discussion