IAM、OAuth、OpenID Connect、SAML、SSO、JWT を一つの記事で理解する

アイデンティティとアクセス管理（IAM）の分野は近年より複雑さを増しました。OAuth、OpenID Connect (OIDC)、SAML、SSO、JWTのような華やかな用語が頻繁に使われますが、それぞれ何を意味し、どのように共に機能するのでしょうか？これらの概念とフレームワークを探索して、より理解しやすく実用的にしましょう。

IAM とは何ですか？#

アイデンティティとアクセス管理（IAM）は、デジタルアイデンティティを管理し、アクセス制御を実装するという広範な概念です。前述のフレームワークとプロトコルは IAM に属し、それぞれこの領域の特定の課題に対処しています。

本質的に、IAM は次のようなものです：

• アイデンティティ: ユーザー、サービス、またはデバイスのデジタル表現。アイデンティティには通常、名前、メール、役割など、エンティティを記述する属性が含まれます。
• アクセス: リソースと対話し、アクションを実行し、またはサービスを使用する能力。アクセスは、どのリソースでどのアクションを実行できるかを定義します。

上の図では、ユーザー（アイデンティティ）は API（リソース）に GET リクエストを実行したいと考えています。ユーザーの属性 - 名前、メール、役割 - はアイデンティティを記述します。

認証と認可#

認証と認可は、IAM の議論でよく一緒に現れます。それらの定義を明確にしましょう：

• 認証: アイデンティティの所有権を確認するプロセスです。「どのアイデンティティを所有していますか？」という質問に答えます。
• 認可: 認証されたアイデンティティがリソースでどのアクションを実行できるかを決定するプロセスです。「何ができますか？」という質問に答えます。

前の例では：

• ユーザー（アイデンティティ）が何らかのアクションを実行する前に、認証プロセスを完了する必要があります。
• 認証後、システムはユーザーが API（リソース）で GET リクエストを実行できるかどうかを判断する必要があります。つまり、認可プロセスを完了します。

---

この基本的な知識を武器に、その他の頭字語とプロトコルを解き明かしましょう。

OAuth#

OAuth 2.0、通常 OAuth として知られるのは、アプリケーションが別のアプリケーション（通常はユーザーを代表して）で保護されたリソースにアクセスすることを可能にする認可フレームワークです。

例えば、MyApp というウェブアプリケーションがユーザーの Google Drive にアクセスしたいと仮定します。MyApp は、ユーザーに Google Drive の資格情報を共有するように求める代わりに、OAuth 2.0 を使用して Google に対しユーザーの Drive へのアクセス権を求めることができます。

以下は OAuth フローを示す簡略化された図です：

このフローでは：

• MyApp は Google Drive（リソース）へのアクセスを要求するクライアント（アイデンティティ）です。
• 手順6でユーザー（リソース所有者）が MyApp に対して許可を与え、認可プロセスが完了します。

OAuth 2.0 の重要な要素はアクセストークンで、クライアントがユーザーのリソースへのアクセス許可を示すために使用します。詳細については、アクセストークンをご覧ください。

OpenID Connect (OIDC)#

OpenID Connect (OIDC) は、OAuth 2.0 上に構築された認証レイヤーです。OIDC は、ID トークンやUserInfo エンドポイントなど、認証のための特定の機能を追加し、認証と認可の両方に適しています。

OAuth フローに OIDC を追加すると、ID トークンが導入されます。このトークンには認証されたユーザーに関する情報が含まれており、MyApp にユーザーのアイデンティティを確認させます。

例シナリオ：「Google でサインイン」#

例を変えてみましょう。MyApp がユーザーに Google アカウントを使用してサインインさせたい場合、目的はリソースへのアクセスではなく認証に切り替わります。この場合、OIDC がより適しています。ここでは OIDC フローが次のようになります：

重要な違い: アクセストークンに加えて、OIDC は ID トークンを提供し、MyApp は追加の要求を必要とせずにユーザーを認証できます。

OIDC は、OAuth 2.0 のグラント定義を共有し、両方のフレームワーク間での互換性と一貫性を確保しています。

SAML#

Security Assertion Markup Language (SAML) は、認証と認可データを交換するための XML ベースのフレームワークです。2000年代初頭に導入された SAML は、企業環境で広く採用されています。

SAML と OIDC の比較#

SAML と OIDC は機能的には似ていますが、その実装の詳細が異なります：

• SAML: XML ベースのアサーションを使用し、より複雑とされることが多いです。
• OIDC: JSON と JWT を活用し、より軽量で開発者に優しいです。

モダンなアプリケーションは、そのシンプルさと柔軟性から OIDC を好むことが多いですが、SAML はレガシーシステムや企業用途で依然として広く使われています。

シングルサインオン（SSO）#

シングルサインオン（SSO） は、ユーザーが複数のアプリケーションやサービスに単一の資格情報でアクセスできるようにする認証スキームです。

SSO の仕組み#

SSO は、中央のアイデンティティプロバイダー (IdP)に依存してユーザーのアイデンティティを管理します。IdP はユーザーを認証し、接続されたアプリケーションに認証や認可のサービスを提供します。

IdP は、OIDC、OAuth 2.0、SAML などのプロトコルを使用してこれらのサービスを提供できます。単一の IdP が複数のプロトコルをサポートし、異なるアプリケーションの多様なニーズに応えることができます。

OIDC ベースの SSO の例#

OIDC ベースの SSO の例を見てみましょう：

このフローでは、ユーザーは IdP に一度ログインし、複数のアプリケーション（AppA と AppB）で認証されます。

企業向け SSO#

SSO は幅広い概念ですが、企業向け SSOという用語に出くわすこともあります。これは、企業環境向けに設計された特定のタイプの SSO を指します（通常は従業員やパートナーのためのものです）。

顧客があなたのアプリケーションに SSO を要求する場合、そのニーズと使用しているプロトコルを明確にすることが重要です。ほとんどの場合、特定のメールドメインについて、彼らの IdP（企業向け SSO を実装している IdP）にユーザーをリダイレクトして認証することが求められます。

企業向け SSO プロバイダーの追加例#

ここに、あなたのアプリケーション（MyApp）が企業向け SSO プロバイダー（Banana）と統合する簡略化された例があります：

JWT#

JSON Web トークン (JWT) は、RFC 7519 で定義されたオープンスタンダードで、2つのパーティ間の安全な通信を可能にします。OIDC での ID トークンの標準形式であり、OAuth 2.0 アクセストークンにも広く使用されています。

JWT の主な特性は次の通りです：

• コンパクト: JWT は JSON オブジェクトをコンパクトにエンコードしたもので、転送しやすく保存しやすいです。
• 自己完結型: JWT にはユーザーとトークン自体に関するすべての必要な情報が含まれています。
• 検証可能かつ暗号化可能: JWT は署名と暗号化が可能で、データの完全性と機密性を確保します。

典型的な JWT は次のようになります：

この JWT は、ピリオドで区切られた3つの部分で構成されています：

• ヘッダー: トークンのメタデータ、例えばトークンタイプと署名アルゴリズムを含みます。
• ペイロード: アイデンティティとトークン自体に関する情報を含みます。
• 署名: トークンの完全性を検証します。

ヘッダーとペイロードはどちらも base64 でエンコードされた JSON オブジェクトです。上記の JWT は次のようにデコードできます：

JWT を使用すると、クライアントはトークンをデコードして、アイデンティティプロバイダーに追加のリクエストを行うことなくユーザーの情報を抽出できます。JWT について詳しく学ぶには、JSON Web トークン (JWT)を訪れてください。

まとめ#

この記事では多くのことをカバーしました。ここで要点を例と共に要約してみましょう：

Web アプリケーション AppA がアイデンティティとアクセス管理（IAM）ソリューションを必要としていると想像してください。あなたは認証のためにOpenID Connect (OIDC) を使用するアイデンティティプロバイダー Logto を選びます。OIDC は OAuth 2.0 の上に構築されているため、Logto はアプリケーションの認可もサポートします。

ユーザーの手間を減らすために、Logto に「Google でサインイン」機能を有効にします。これは OAuth 2.0 を使用して、Logto と Google の間で認可データとユーザー情報を交換します。

ユーザーが Logto 経由で AppA にログインすると、AppA はユーザー情報を含む JSON Web トークン（JWT） を受け取ります。

事業が成長すると、ユーザー認証を必要とする新しいアプリケーション AppB を立ち上げます。Logto が既に設定されているので、AppB に同じ認証フローを再利用できます。ユーザーは、単一の資格情報セットで AppA と AppB の両方にサインインできるようになります。この機能はシングルサインオン (SSO) として知られています。

後に、ビジネスパートナーが SAML を使用した企業向け SSO システムを接続することを要求します。Logto が SAML 接続をサポートしていることを発見し、パートナーの SSO システムと Logto との間に接続を設定します。これで、パートナーの組織のユーザーも既存の資格情報を使って AppA と AppB にサインインできるようになります。

---

この記事がこれらの概念を明確にするのに役立ったことを願っています。さらに詳しい説明や例については、Auth Wikiをチェックしてください。アプリケーションの IAM ソリューションを探しているなら、Logto のような管理サービスを使用して時間と手間を節約することを検討してください。