OAuthとSAMLの違いをざっくり理解！中学でもわかる認証と承認の秘密

---

OAuthとSAMLの違いを徹底解説

OAuthとSAMLはどちらも「誰が何をできるか」を決める仕組みですが、使われる場面や仕組みの作りが大きく違います。この記事を読んでいるあなたにも伝わるよう、まずは日常の例えから始めます。OAuthは「第三者に対して権限を渡して、特定の資源へアクセスさせる仕組み」を指します。つまり、あなたが写真やデータをあるアプリに見せたいとき、あなたのIDを直接渡すのではなく、承認の結果として発行されるアクセストークンを使ってアクセスを許可します。これにより、機密情報を丸ごと渡す必要がなくなります。OAuthはウェブAPIのやり取りに向いており、PCやスマホのアプリ間で安全に機能を組み合わせるのが得意です。なお、OAuth単体では認証（"私が誰かを証明すること"）は保証されません。認証を組み合わせるのがOpenID Connectという別の仕組みです。PKCEという追加の安全策を使えば、公開クライアントの認証をより安全に行えます。
ここまでの説明で、認証と承認、そしてトークンの役割が少し見えてきたはずです。

OAuthとは何か

OAuthとは、第三者アプリに対してあなたのIDを直接渡すことなく、特定の機能へアクセスする権限を渡す仕組みです。認証と承認を分けて考える点が特徴で、前者は「この人が本当にこの人かを確かめること」、後者は「この人にどの機能を使わせて良いかを決めること」です。OAuthの流れは大まかに次のようになります。まずアプリがあなたを認証するために認可サーバーへ誘導します。あなたが正しく認証すると、認可サーバーはアプリに対して一時的なコードを返します。アプリはそのコードを使って認可サーバーからアクセストークンを受け取り、必要なときに資源サーバーへアクセスします。アクセストークンは期限が決まっていて、長い間使われることはありません。さらに、期限が切れた場合にはリフレッシュトークンを使って新しいアクセストークンを取得することができます。この設計により、パスワードや機密情報をアプリに渡す必要がなく、安全な運用が可能になります。
また、PKCE（Proof Key for Code Exchange）と呼ばれる追加の安全策を使えば、公開クライアントのセキュリティをさらに高められます。PKCEは特にモバイルアプリやクライアント側のアプリで有効で、認可コードの盗用リスクを減らします。これらの点を踏まえると、OAuthは「APIの権限付与を管理する仕組み」であり、トークンを介した信頼の伝達が基本です。

SAMLとは何か

SAMLはXMLベースの認証と承認の仕組みで、主に企業のシングルサインオン（SSO）に使われます。ここでの登場人物は IdP（Identity Provider、IDを管理する側）と SP（Service Provider、サービスを提供する側）です。利用者が企業のWebアプリにログインする際、ブラウザは IdP にリダイレクトされ、そこで認証が行われます。IdP が認証を通じると、SAMLアサーションと呼ばれるXML形式の証明書のような“合言葉”が作成され、サービス提供側へ送られます。SP はこのアサーションを検証し、本人としてログインを許可します。SAMLはブラウザベースのSSOを前提に作られており、企業内の複数のサービスで同じ IdP を使って一度のログインで済ませることが可能です。
この流れは、アサーションと呼ばれるXMLの証明書に基づく認証方法で、トークンよりも長期的な信頼関係を前提とします。SAMLは歴史が古く、企業規模の導入で根強い信頼があります。

技術的な違いと使い分け

OAuthとSAMLの技術的な違いは主に「トークンの形」と「認証の場面」です。OAuthはアクセストークンとリフレッシュトークンを用い、APIアクセスの権限付与を行います。形式は基本的にJSON、HTTPのセキュアな経路でやり取りします。SAMLはXMLベースのアサーションを使い、主にWebブラウザ上のSSOを実現します。つまりOAuthはAPI中心、SAMLはWebのSSO中心と覚えると混乱を避けられます。使い分けのポイントとしては、企業の内部サービスを一括でログインさせたい場合はSAML、外部サービスとのAPI連携やモバイル・アプリの認証にはOAuth（とOIDCを使うのが一般的）を選ぶのが基本です。セキュリティ面では、PKCEの導入や、トークンの有効期限管理、適切なスコープ設定、リダイレクトURIの厳格な管理が重要です。

実務での導入シーンと注意点

実務の現場では、まず要件を整理してから選択します。ユーザーのログイン体験を重視する場合は、SAMLよりOAuth/OIDCを選び、ウェブとモバイルの連携をスムーズにします。企業内のシングルサインオンサービスがすでに整備されている場合は、SAMLを採用して IdP の統合を行うケースが多いです。IDプロバイダの例として Azure AD、Okta、ADFS などがあります。導入時の注意点としては、トークンの盗用を防ぐための PKCE の利用、シークレット情報の適切な管理、メタデータの正確な交換、リダイレクトURIの厳格な制御、ログと監査の整備などが挙げられます。運用では、トークンの失効やローテーション、セキュリティポリシーの更新を定期的に行い、ユーザー教育も欠かさず行います。

まとめ

この二つの仕組みを正しく理解すると、“どの場面でどの仕組みを使うべきか”が見えてきます。要点としては、OAuthはAPIアクセスの権限を付与する仕組み、SAMLは企業のSSOを実現する仕組みという点です。中学の友達に例えるなら、OAuthは「あなたの代わりにアプリが動く許可を渡すカード」、SAMLは「学校の入り口を一度の手続きで済ませる学校の合言葉」みたいな感じです。現代のシステムでは、OIDCを使って認証と承認をセットで扱うのが一般的になっています。適切な選択と安全な運用を心掛けましょう。

able>要点OAuthSAML主な用途APIの権限付与・アクセス企業内SSO・Webログイントークン/証明書アクセストークン、リフレッシュトークンXMLアサーション典型的な環境モバイル・Webアプリの連携企業のIdPとSPの組み合わせble>

ピックアップ解説

昨日の放課後、友だちとOAuthとSAMLの話をしていて、違いの本質は“誰を信じるかとどう証明するか”だと気づきました。OAuthは「私の名前を渡さずに、私がこのアプリを使う権利を渡す」仕組みで、SAMLは「企業のIDで一度ログインして、複数のサービスに自動で入る」仕組みです。日常のアプリの動作も、いま自分たちが使っているオンライン体験の背後でこれらの考えが動いていると考えると、ちょっとおもしろく感じませんか。学年が上がるにつれて、こうした認証の仕組みをどう学ぶかが、ITを学ぶ第一歩になるんだと思います。

---