見出し画像

『分かりやすいOAuthとSAML』的な説明が分からなかった人へ 〜 現実に喩えて分かった気になる説明

新しいサービスを使い始める時、"Sign in with Google"みたいなアイコンが表示され、すでにあるGoogleでの登録情報を使って、簡単に登録・ログインできる体験に馴染みのある方は多いと思います。これはOAuth 2.0と言われる仕組みを使っています。

一方、企業に属している方は、特定のサービスを使う時にSAML用のログインページ(例:Okta)に誘導され、まずは(Oktaで)ログインしてからサービスを使い始めることができるという体験をしたことあるかもしれません。これはSAMLと言われる仕組みを使っています。

OAuth 2.0SAMLで似たようなログインをしている気がしますが、この2つは何が違うのでしょうか。この記事の焦点はそこになります。

よく見かける説明

以下のような説明をよく見かけますが、イメージがつかない人は多いと思います😢(実際、分かりやすいはずですが)

Security assertion markup language (SAML)とは認証プロセスです。
...
ネットワーク管理者がSAMLを使って、ユーザーを中央集権的に管理します。1つのパスワードが全てのサービスへのアクセスを解放し、企業のセキュリティを守ります。
Open authorization (OAuth)とは認可プロセスです。
...
このプロトコルはユーザーのusernameとpasswordを守りながら認可をある場所から他の場所へ通します。

上記のような説明も、現実で馴染みのある他のものに喩えて理解すると分かりやすくなると思います。

よく言われる特徴の違い(しかし、ピンとこない)

・SAMLは認証(Authentification)でOAuthは認可(Authorization)
・SAMLはEnterprise SSO (= 全ケースで理想という訳ではない)
・SAMLの方がなりすましの検証があるので、セキュリティが高い
・両方のシステムがその性質ゆえに、認証も認可もある程度兼ねる

なぜ、こういう特徴になるのか分かるように説明していきます (`・ω・´)ゞ

OAuthを喩えると?

こちらの方が性質上、色々な場面で使われやすいと思います。
(生年月日・氏名などを確認するための)運転免許証とそのシステムと思ってもらうと良いです。

あなたはお酒を飲むために居酒屋へ入る。
20歳以上を証明するために、車の運転免許証を提示する。
この際、本人確認というよりは20歳以上を分かる何かが欲しい 。
社会人でも大学生でも僧侶でも、20歳以上なら居酒屋でお酒を頼める。

この場合、『あなたは何者か』が目的ではないと分かると思います。
本人確認(認証)よりも許可(認可)が目的だからです。

OAuthの具体的な処理を喩えると?

Request: A user clicks on a "Log in" button on a web page.
Choice: The client chooses the third-party authorization credentials to use.
Log in: The authorization server creates an access token, and that’s sent to the resource server.
Connection: After verifying the token, the resource server grants access.

1. お客が居酒屋に入店する。
2. お客は自分が20歳以上であることを身分証明できるモノを選ぶ。(例:運転免許証)
3. (ここは現実ではありえないが)身分証明の団体(運転免許センター)は身分証明書を発行する。
4. 居酒屋は身分証明書を確認し、お酒を頼むことを許可する。

3の部分はセキュリティを高めるため、訪れる居酒屋ごとに身分証明の団体は身分証明書を発行しています。

OAuthの特徴1:色々な居酒屋で同じ身分証明書が使える

 運転免許証さえあれば色々な居酒屋でお酒を飲める。言い返せば、居酒屋ごとに独自の許可証を持つ必要はない。

居酒屋同士でお互いに協力していないのに、運転免許証という信頼をベースに居酒屋も客も行動しています。(後のSAMLではこれが面倒なことが分かります。)

OAuthの特徴2:1つの居酒屋で色々な身分証明書が使える

20歳以上を示すのに、運転免許証を持ってなければパスポート、マイナンバーカード、健康保険証、社員証、(大学)学生証でも良い。

複数の『一般的に認知・信頼のある証明書』が使われています。(後のSAMLでは基本的に1つなことが分かります。)

SAMLを喩えると?

こちらは企業で使われていたり、有名な業務アプリのログインの説明で出てきたりします。

結婚式の招待状と招待リスト、受付のシステムと思ってもらうと良いです。結婚式場は大きく、いくつものカップルが同時に結婚式を挙げていると思ってください。

あなたは友人の大きめの結婚式に招待されたゲストである。
友人は事前にあなたをゲストとして招待リストに登録を済ませており、あなたは招待券をもらっている。
あなたは結婚式場に入り、総合受付で、(友人にではなく)受付スタッフに招待券を渡す。
まず、受付スタッフは招待券に書かれている氏名が招待リストにあるか確認する。
次に、受付スタッフは身元のわかる証明書の提示をあなたにお願いする。
招待の確認と身元確認が済めば、あなたはゲスト用の入場券をもらって友人の結婚式の会場に案内されて入る。

この場合、『あなたは何者か』が主目的であると分かると思います。(本当に招待されているか&招待された本人かどうか)

認可(許可すること)よりも認証(本人確認)が目的だからです。

SAMLの具体的な処理を喩えると?

Request: A user taps on a "Log in" button.
Validation: The SAML and the identity provider connect for authentication.
Login: The user sees a screen waiting for username and password data.
Token creation: If the user enters the right information, a SAML token moves to the service provider, which allows the user to log into the server.

1.(いくつもの結婚式を同時にしている)結婚式場に入る
2. 結婚式場の総合受付に行く
3. (本人と分かる顔写真入りの)身分証明書と招待券を提示する。
4. ゲスト用の入場券をもらって友人の会場に案内されて入る

SAMLの特徴1:許可する役割も間接的にできる

入場する時にあなたはゲスト用の入場券をもらったので、食事を食べれます。親族用の入場券をもらった人は特別な席に座っています。

入場する時の入場券が許可証にもなっています。ただし、総合受付では入場券の管理しかしておらず、具体的な許可する内容は会場の運営側で決まります。

OAuthとSAMLの組み合わせを喩えると?

結婚式場に入る時は招待リストと身元の確認する。
会場内でお酒を飲む時は(年齢の分かる)運転免許証を見せる。

このようにOAuthの特徴とSAMLの特徴を組み合わせることが可能です。

OAuthの使い所は?

もう直感的に分かると思いますが、OAuthで十分なケースが多いです。

現実の世界でも、特定のサービスを受けるために年齢確認や性別確認などをする方が、本人確認をする必要があるケースよりも多いです。

また、OAuthでは細かい許可も出せます。例えばGoogleのOAuthで『この会社のメールのドメインを持っている人だから、このサービスを使って良い。』が可能です。

現実の世界でも、運転免許証の中に二輪免許があれば、バイクを運転できるのと同じです。

SAMLの使い所は?

銀行口座を開設する時など、本人であることが重要な場合は本人確認をする必要がある。写真入りの身分証明書での照会が行われる。

企業ではこのように本人確認をさせたい重要な利用ケースが多く、SAMLを使う動機があります。

それはSAMLがEnterprise SSOと言われるゆえんだと思います。

Single sign-on (SSO)とは?
認証を1度行うだけで、複数のWebサービス・クラウドサービス・アプリケーションにログインできるようにする仕組み

この点はやはりOAuthでは保証しづらいです。(現実では写真のない学生証でなりすましができるように)

ちなみに、SAML以外のWeb上で行われる本人確認では本人しか知りえないだろう情報を求める場合もあります。自分の誕生日やペットの名前を追加で入力させるといえば、覚えのある人も多いと思います。

OAuthとSAMLの喩えと実際の専門用語の比較すると?

OAuthの専門用語

身分証明をする団体(運転免許更新センターなど) → Authorisation Server
身分証明書(運転免許証) → Access Token
お酒を提供する居酒屋 → Resource Server

SAMLの専門用語

総合受付 → Identity Provider (IdP)
各々のイベント会場 → Service Provider

この後に読むと分かるかもしれない本当のドキュメント

上記で出てきた単語を読み替えると下のドキュメントは分かりやすいと思います。


この記事が気に入ったらサポートをしてみませんか?