【図解あり】SSO・Kerberos認証・SAML・OIDC・OAuthの違いの理解不足に終止符を打つ
はじめに
Webシステム関連の業務を遂行する上で、認証関連の用語(SSO, Kerberos認証, SAML, OIDC, OAuth)を目にする機会は多いですよね。
これらの用語の違いを言えますか？使い分けをできますか？な～んとなく理解してるけれど、口頭で説明しろと言われると難しい…という方も多いのではないでしょうか。
そう、私もその1人です...
そこで、自身の学習がてら備忘録としてまとめました。私と状況が似ている方、ご参考になれば幸いです。
結論
超端的に結論です。
〇 SSO(Single Sign-On)
概念です。
どんな概念？ 一度の認証で複数サービスを横断的に利用できる概念です。
SSOの実現には様々な方法があります。それが1つ下の3つの認証です。
〇 Kerberos認証, SAML, OIDC
認証プロトコルです。SSOを実現するためのものです。
各違いについては、詳細にまとめています。
〇 OAuth2.0
認可プロトコルです。
単体ではSSOを実現できないです。
詳細
1. SSO(Single Sign-On)
■ SSOとは
SSOは、一度の認証で複数のサービスを利用できるようにする概念です。
例としては、Googleアカウントでログインをすると、Gmail, Google Drive, YouTubeなど、Googleの複数のサービスにログインできるようになりますよね、あれです。
↑おおよそSSOのイメージは掴めていると思うので、ここではメリットだけ触れてKerberos認証, SAML, OIDCの詳細に移りたい思います。
■ メリット
〇 ユーザビリティの向上
これは誰でもわかりますよね。一回のログインで複数のサービスを利用できるので、ユーザは毎回ログインする手間が省けます。
〇 セキュリティの向上
パスワードの管理が一元化、セキュリティポリシーを統一できるため、セキュリティが向上します。認証情報がトークンとして扱われるため、漏洩リスクも低減します。
〇 運用の効率化
運用側も、ユーザ管理や認証情報の管理が一元化されるため、運用コストが削減されます。
2. Kerberos認証
■ Kerberos認証とは
Kerberos認証は、SSOを実現するための認証プロトコルの一つです。
他の認証との違いとしてはチケットベースの認証方式です。
例としては、遊園地を想像をしてもらえると分かりやすいと思います。入場チケットを元に、アトラクションチケットを受け取るイメージです。
以下、Kerberos認証の説明では遊園地を例とさせてもらいます。
詳細は■ 認証フローに記載しているので、見てみてください。
■ 特徴
〇 チケットベースの認証
ユーザは一度ログインすると、チケットを受け取ります。このチケットを使って、他のサービスにアクセスできます。
チケットはHTTPリクエストのヘッダーで送付します。
〇 主に社内システムで利用
WindowsのActive Directoryなどに、Kerberos認証の機能があるため、社内ネットワークで利用されることが多いです。
■ 登場人物
暗記する必要はありませんが、理解しておくと認証フローが分かりやすくなると思います。
-
KDC（Key Distribution Center）: Kerberos認証の中心となるサーバ。認証&チケットの配布を行う。遊園地における入場券販売窓口。KDCは以下で構成。
- AS（Authentication Server）: 認証サーバ。ユーザ認証&配布用チケット（TGT: Ticket Granting Ticket）を発行。遊園地における入場券販売窓口。
- TGS（Ticket Granting Server）: チケット付与サーバ。配布用チケットを確認&サーバーアクセス用チケット（ST: Service Ticket）を発行。遊園地におけるアトラクションチケット交換所。
-
TGT（Ticket Granting Ticket）: 配布用チケット。ASにて発行。TGSにてSTを取得するために使用される。遊園地における入場券に当たります。
-
ST（Service Ticket）: サーバーアクセス用チケット。TGSにて発行。これにより、目的のサービスにアクセスできる。遊園地におけるアトラクションチケット。
■ 認証フロー
Kerberos認証のフローです。
今回は他の認証との違いに重点を置いているため、タイムスタンプや暗号化の詳細は省略します。
フロー②で取得した配布用チケット（TGT）は、使いまわしが出来るため、これによりSSOが実現します。
-------------こちらに例を記載します
①ユーザは認証サーバ(AS)にIDとパスワードを送信。
②認証サーバ(AS)はIDとパスワードの検証が成功すると、配布用チケット（TGT）を発行。
-------------①②来園者は遊園地の入場チケットを購入します。
③ユーザはチケット付与サーバ(TGS)に配布用チケットを送信。
④③の検証が成功すると、サーバーアクセス用チケット（ST: Service Ticket）を発行。
-------------③④入場チケットをもとに遊園地のアトラクションチケットを購入します。
⑤ユーザはサーバーアクセス用チケット（ST）を使って、目的のサービスにアクセス。
⑥サーバはサーバーアクセス用チケット（ST）の検証&サービス提供。
-------------⑤⑥アトラクションチケットを見せて、アトラクションに乗ることが出来ます。
※例だとこんなフロー
3. SAML(Security Assertion Markup Language)
■ SAMLとは
こちらもSSOを実現するための認証プロトコルの一つです。
他の認証との違いとしてはXMLを利用した認証であることです。SAMLはXML形式の認証情報を格納し、送信します。
SAMLの説明ではホテルのレストラン利用を例とさせてもらいます。レストラン利用にはホテルの宿泊証明証が必要です。レストラン利用者は宿泊証明証をフロントで受け取ってからでないと、レストランは利用できません。
■ 特徴
〇 XMLベースの標準
SAMLはXMLを利用した認証で、認証情報をセキュアに交換するためのプロトコルです。
XML形式の認証情報は、リダイレクトURLのクエリパラメータやHTTP POSTリクエストのボディで送付されます。
■ 登場人物
暗記する必要はありませんが、理解しておくと認証フローが分かりやすくなると思います。
- IdP（Identity Provider）: 認証サーバ。例における受付フロント。
- SP（Service Provider）: サービスプロバイダ。サービスを提供するサーバ。例におけるレストラン。
- アサーション（Assertion）: 認証情報を含むXMLドキュメント。IdPがSPに送信。例における宿泊証明証。
■ 認証フロー
SAMLのフローです。
-------------こちらに例を記載します
①ユーザはサービスプロバイダ(SP)にアクセス。
-------------ホテルのレストランへ行きます
②ログイン済みセッションがないことを検知し、サービスプロバイダ(SP)は、認証サーバ(IdP)へのリダイレクトレスポンスと認証依頼情報(XML)をユーザへ返却。
-------------レストランは「宿泊者確認が必要のため、フロントで宿泊証明証をもらってください」と伝えます。
③ユーザはリダイレクトに従って認証依頼情報(XML)を含み認証サーバ(IdP)へリクエスト。
-------------フロントへ行き、宿泊証明証を要求します。
④認証サーバ(IdP)は、認証依頼情報(XML)を検証して、ユーザ認証用のログイン画面をユーザへ返却。
-------------フロントは氏名を聞きます。
⑤ユーザは認証サーバ(IdP)にID&パスワードを送信。
-------------氏名をフロントへ伝えます。
⑥認証サーバ(IdP)はID&パスワードの検証＆サーバ(SP)へのリダイレクトレスポンスと認証情報(XML)をユーザへ返却。
-------------フロントは氏名を確認して宿泊証明証を渡します。
⑦ユーザはリダイレクトに従って認証情報(XML)を含みサービスプロバイダ(SP)へリクエスト。
⑧サービスプロバイダ(SP)は認証情報(XML)の検証が成功すると、ユーザにサービスを提供。
-------------宿泊者証明書を見せてレストランを利用できます。
例だとこんなフロー
4. OAuth2.0
OIDCについて触れたいところですが、先にOAuth2.0についてまとめさせてください。
というのも、OIDCはOAuth2.0の拡張仕様であり、OAuth2.0を先に理解した方がOIDCの理解が深まるからです。
■ OAuth2.0とは
OAuth2.0は、**認可（Authorization）**を行うためのプロトコルです。
ユーザーの「本人確認（認証）」ではなく、
「特定のクライアントに対し、限定的にアクセス権を与える」ために利用されます。
認証が必要な場合は、OAuth2.0の拡張仕様である**OIDC（OpenID Connect）**を使います。
例については思いつかなかったので妥協させてください...
■ 登場人物
暗記する必要はありませんが、理解しておくと認証フローが分かりやすくなると思います。
- リソースオーナー（Resource Owner）: ユーザ本人。
- クライアント（Client）: 保護されたリソースにアクセスするアプリケーションやサービス。例：Webアプリケーション、API、モバイルアプリ。
- 認可サーバ（Authorization Server）: リソースオーナーの認可&アクセストークンを発行するサーバ。
- リソースサーバ（Resource Server）: 保護されたリソースを提供するサーバ。クライアントからのアクセストークン検証し、アクセスを許可する。
- アクセストークン（Access Token）: クライアントがリソースサーバにアクセスするためのトークン。認可サーバから発行される。
■ 認可フロー
OAuth2.0にはいくつかのフローがあります。
- Authorization codeフロー
- Client Credentials フロー
- Implicit フロー
- Resource Owner Password Credentials フロー
- Refresh Token フロー
今回は一般的に利用されるAuthorization codeフローをまとめます。
①リソースオーナーがクライアントにアクセス。
②クライアントはリダイレクトレスポンスと認可依頼情報をリソースオーナーへ返却。
③リソースオーナーはリダイレクトに従って認可依頼情報を認可サーバへリクエストします。
④認可サーバは、認可依頼情報の検証&リソースオーナーへ認可用のログイン画面を返却。
⑤リソースオーナーは認可サーバにIDとパスワードを送信。
⑥認可サーバはIDとパスワードの検証&クライアントへリダイレクトレスポンスと認可コードをリソースオーナーへ返却。
⑦リソースオーナーはリダイレクトに従っての認可コードを含みクライアントへリクエスト。
⑧クライアントは、認可サーバにアクセストークン取得のため、認可コードを含みリクエスト。
⑨認可サーバは、認可コードの検証&アクセストークンを発行し、クライアントへ返却。
⑩クライアントは、アクセストークンを使って保護されたリソースサーバへリクエスト。
⑪リソースサーバはアクセストークンの検証&保護されたリソースをクライアントへ返却。
⑫クライアントは、保護されたリソースをリソースオーナーへ返却。
その他フローは以下の記事が分かりやすく、参考になりました。
5. OIDC（OpenID Connect）
■ OIDCとは？
OIDC（OpenID Connect）は、OAuth2.0をベースに拡張された認証プロトコルです。
OAuth2.0が「認可（何ができるか）」を扱うのに対し、OIDCは「認証（誰であるか）」を扱います。
つまり、OAuth2.0では「本人確認」はできません。
OIDCは、それを補うために作られた**"OAuth2.0に認証を追加する仕組み"**です。
■ OIDCの特徴
〇 認可＋認証
OAuth2.0でアクセストークンを取得しつつ、IDトークンでユーザーの「本人確認」ができます。
〇 IDトークン
ユーザーの認証情報を含むトークン。JWT形式(JSON Web Token)で署名付きで提供されます。
JWT形式はJSONで表現された認証情報を安全に送受信するための標準規格になります。
〇 標準エンドポイント
/authorize, /token, /userinfo などが定義されているため、クライアントはこれらのエンドポイントを利用して認証を行えるため、実装が容易になります。
JWT形式については、以下の記事が参考になりました。
■ OIDCの登場人物
暗記する必要はありませんが、理解しておくと認証フローが分かりやすくなると思います。
- リソースオーナー（Resource Owner）: ユーザ本人。
- クライアント（Client）: 保護されたリソースにアクセスするアプリケーションやサービス。例：Webアプリケーション、API、モバイルアプリ。
- 認可サーバ（Authorization Server）: リソースオーナーの認可&アクセストークンを発行するサーバ。
- リソースサーバ（Resource Server）: 保護されたリソースを提供するサーバ。クライアントからのアクセストークン検証し、アクセスを許可する。
- アクセストークン（Access Token）: クライアントがリソースサーバにアクセスするためのトークン。認可サーバから発行される。
- IDトークン（ID Token）: ユーザの認証情報を含むトークン。JWT形式で提供される。
■ OAuth2.0との違い（まとめ）
| 項目 | OAuth2.0 | OIDC |
|---|---|---|
| 主目的 | 認可 | 認証＋認可 |
| トークン | アクセストークン | アクセストークン＋IDトークン |
| ユーザー情報取得 | APIアクセスで別途取得 | IDトークン or /userinfo で取得可能 |
| フロー | 認可コードフローなど | OAuth2.0と同じ＋IDトークン取得が追加される |
| SSO対応 | 非対応 | 対応（トークンベースで可能） |
■ 認証フロー
認証フローですが、情報の流れとしてはOAuth2.0の認可コードフローと同じです。
プラスで認証のためのIDトークンが取得される点が異なります。
①ユーザーがクライアントにアクセス。
②クライアントはリダイレクトレスポンスをユーザへ返却。
③ユーザは②の認証依頼情報を元に認可サーバ(Authorization Server)へリクエスト。
④認可サーバ(Authorization Server)は、認証依頼情報を検証して、ユーザ認証用のログイン画面を返却。
⑤ユーザは認可サーバ(Authorization Server)にIDとパスワードを送信。
⑥⑤の検証が成功すると、認可サーバ(Authorization Server)は、クライアント(Client)へのリダイレクトレスポンスを認可コード+OIDC認証リクエストパラメータを含みユーザへ返却。
⑦ユーザはブラウザのリダイレクトに従って認可コード+OIDC認証リクエストパラメータ含むリクエストをクライアントに送信。
⑧⑦の検証が成功すると、クライアント(Client)は、認可サーバ(Authorization Server)にアクセストークン+IDトークンをリクエスト。
＋ 認可コード+OIDC認証リクエストパラメータを送信。
⑨認可サーバ(Authorization Server)は、アクセストークン+IDトークンを発行し、クライアント(Client)に返却。
⑩クライアント(Client)は、IDトークンを検証&アクセストークンを使って保護されたリソースサーバへリクエスト。
⑪⑩の検証が成功するとリソースサーバは、保護されたリソースをクライアントへ返却。
⑫クライアント(Client)は、保護されたリソースをユーザへ返却。
最後に
以上になります。呼んでいただいた方、ありがとうございました。
もし、間違いや補足情報があれば、コメントお願いします。。
参考資料
Discussion