Architecture Decision Record
← 決定記録の例

アーキテクチャ決定記録: 認証と認可のオプション

Web アプリケーションの認証と認可は、アプリケーションやサービスへのアクセスを保護するための 2 つの重要な概念です。どちらもユーザーの身元と権限の付与方法に関わりますが、焦点を当てる側面が異なります:

  • 認証(Authentication) は、ユーザーまたはシステムの身元を確認するプロセスです。
  • 認可(Authorization) は、認証されたユーザーまたはシステムがアクセスできるリソースや操作を決定するプロセスです。

それでは、最新の Web アプリケーションで認証と認可を管理するためによく使用される、ご指定のプロトコルと技術を詳しく見ていきましょう。

1. OAuth(Open Authorization)

OAuth は認可のためのオープン標準です。これにより、ユーザーは資格情報を共有することなく、サードパーティのアプリケーションに自分のリソースへの限定的なアクセスを付与できます。重要な考え方は委任されたアクセスです。OAuth は、ユーザーがサードパーティに直接ユーザー名とパスワードを渡すことなく、サードパーティのサービスにログインできる状況(たとえば、Google でサインイン)でよく使用されます。

  • フロー: OAuth は通常、トークンベースのフローに従います。認可サーバーがサードパーティのアプリケーションにアクセストークンを発行します。このトークンはユーザーの権限を表し、アプリケーションはこれを使用して API からユーザーのデータやリソースにアクセスします。
  • 例: ユーザーが Google アカウントを使用してサードパーティアプリにサインインします。Google はユーザーの身元を確認し、サードパーティアプリが一部の Google データ(たとえば Google カレンダー)にアクセスできるトークンを付与します。

OAuth は認証を直接扱いません。アクセスの付与に関するものです。認証のために、OAuth は OpenID Connect などの他のプロトコルと組み合わせて使用されることがよくあります。

2. OpenID Connect(OIDC)

OpenID Connect(OIDC) は、OAuth 2.0 の上に構築された ID レイヤーで、OAuth の認可機能に認証を追加します。本質的に、OpenID Connect は OAuth を拡張してユーザー認証を扱えるようにし、アプリケーションがユーザーの身元を確認するための標準的な方法を提供します。

  • フロー: ユーザーが OpenID Connect を使用してログインすると、サードパーティのアプリケーションは(OAuth アクセストークンに加えて)ID トークンを要求します。ID トークンには、ユーザーに関する情報(ユーザー名、メールアドレス、その他のクレームなど)が含まれます。これにより、アプリケーションはユーザーが誰であるか、また認証されているかどうかを知ることができます。
  • 例: Google アカウントを使用して Slack のようなサービスにログインする場合(Google が OpenID Connect プロバイダー)、OpenID Connect による認証が行われ、OAuth は Google リソースへのアクセスを管理します。

OIDC により、サードパーティアプリがユーザーを認証することが容易になり、同時に、それらのアプリがアクセスできるリソースをきめ細かく制御することも可能です。

3. SAML(Security Assertion Markup Language)

SAML は、特に**シングルサインオン(SSO)**のシナリオで、当事者間で認証および認可データを交換するために使用される、XML ベースの古い標準です。主にエンタープライズ環境で、ユーザーが一度認証するだけで、資格情報を再入力することなく複数のアプリケーションにアクセスできるようにするために使用されます。

  • フロー: ユーザーはまず ID プロバイダー(IdP)で認証します。IdP は、ユーザーの身元と関連する属性を含む署名付きの SAML アサーションを生成します。アサーションはサービスプロバイダー(SP)に送信され、SP はそれを使用してアプリケーションへのアクセスを認可します。
  • 例: 従業員が企業ポータル(IdP)にログインすると、資格情報を再入力することなく、メール、CRM などの他のシステムに自動的にログインされます。認証プロセスは、IdP から送信された SAML アサーションに基づいています。

SAML はエンタープライズ SSO ソリューションで一般的に使用され、企業環境の Web アプリケーションではうまく機能しますが、OAuth/OIDC に比べてモバイルフレンドリーではありません。

4. WS-Federation(Web Services Federation)

WS-Federation は、特に Microsoft ベースのエンタープライズ環境で、**シングルサインオン(SSO)**に使用される別のプロトコルです。**WS-*(Web Services)**仕様ファミリーの一部であり、異なるセキュリティドメイン間(異なる組織間や異なるサービス間など)での ID フェデレーションを可能にします。

  • フロー: WS-Federation では、**信頼された ID プロバイダー(IdP)**がユーザーを認証し、サービスプロバイダーが認可に使用できるトークンを発行します。SAML に似ていますが、Microsoft テクノロジーに大きく依存するシナリオでよく使用されます。
  • 例: ユーザーが Microsoft Azure Active Directory(AD)でホストされているエンタープライズアプリケーションにログインし、その ID を使用して、サードパーティベンダーがホストするアプリケーションを含む他のフェデレーションサービスにアクセスできます。

WS-Federation は、最近の多くの Web 環境では OAuth2.0 や OpenID Connect などの新しいプロトコルにほぼ置き換えられていますが、特に Microsoft 中心の企業では、レガシーシステムで今も使用されています。

5. LDAP(Lightweight Directory Access Protocol)

LDAP は、ディレクトリサービスにアクセスして管理するために使用されるプロトコルで、一般にユーザー資格情報の保管や、中央集約型ディレクトリ(しばしばディレクトリサービスと呼ばれる)でのアクセス制御の管理に使用されます。LDAP は認証や認可そのものに関するものではなく、ID データを保存・取得するために使用され、そのデータがこれらのプロセスで利用されます。

  • 認証: LDAP により、アプリケーションはディレクトリサービスに資格情報(パスワードなど)を問い合わせることでユーザーを認証できます。
  • 認可: LDAP はユーザーの役割と権限も管理し、ユーザーが特定のリソースにアクセスできるかどうかの判断を助けます。
  • 例: 多くの企業は、特に Windows 環境で、認証と認可に LDAP ベースのディレクトリ(たとえば Active Directory)を使用しています。

LDAP は、企業が内部システム全体のユーザーアクセスを管理するために不可欠ですが、現代の Web のコンテキストでは、より完全な ID 管理のために、LDAP は SAML や OAuth などの他のプロトコルと統合されることがよくあります。

6. ソーシャル SSO プロバイダー

Facebook、Google、Twitter、GitHub などのソーシャルシングルサインオン(SSO)プロバイダーにより、ユーザーはソーシャルメディアの資格情報を使用してサードパーティのアプリケーションに認証できます。これはOAuth ベースの認証の一種で、サードパーティサービス(たとえば Google)が ID プロバイダーになります。

  • フロー: ユーザーが(たとえば)「Google でログイン」をクリックします。アプリは Google にリダイレクトし、ユーザーはそこでログインします(まだログインしていない場合)。その後、Google はサードパーティアプリにアクセストークンまたは ID トークンを提供し、それを使用してユーザーを認証し、場合によってはそのデータにアクセスできます。
  • 例: 多くのアプリケーションでは、Google や Facebook の資格情報を使用してログインできます。アプリは裏で OAuth や OpenID Connect を使用してあなたの身元を確認し、場合によっては特定のソーシャルメディアデータにアクセスします。

ソーシャル SSO は、新たなユーザー名とパスワードを作成したくないユーザーの手間を減らすため、便利で広く採用されている認証方法です。

違いのまとめ:

  • OAuth: 認可に使用され、資格情報を公開せずにサードパーティアプリがユーザーデータにアクセスできるようにします。
  • OpenID Connect: OAuth を拡張して認証を提供し、アプリがユーザーの身元を確認できるようにします。
  • SAML: SSO に使用される XML ベースのプロトコルで、しばしばエンタープライズ環境で使われます。
  • WS-Federation: ID フェデレーションのための Microsoft 固有のプロトコルで、レガシーシステムで使用されます。
  • LDAP: ユーザーを認証し、認可を管理するためにディレクトリサービスに問い合わせるためのプロトコルです。
  • ソーシャル SSO プロバイダー: ソーシャルメディアの資格情報を使用して、サードパーティアプリがユーザーを認証できるようにする OAuth ベースのシステム(Google、Facebook など)です。

これらの技術にはそれぞれ長所とユースケースがあり、現代のアプリケーションでは、セキュリティのさまざまな側面(たとえば、API アクセスには OAuth/OIDC、エンタープライズ SSO には SAML)にそれらの組み合わせが使用されているのを目にすることがあります。