Webエンジニアなら知っておきたいIDaaS

Web エンジニアなら知っておきたい

はじめに

こんにちは、クラウドネイティブ技術部の平田です。

昨今、ほとんどのWebアプリケーションにおいて認証・認可の機能は必須となっています。

これらの機能を提供する認証基盤は、セキュリティなどの観点からシステム上非常に重要です。 認証基盤の実装に脆弱性があると、個人情報漏洩などの重大なセキュリティインシデントに繋がる可能性があります。

しかし、認証・認可はアプリケーションが本来提供したい価値そのものではありません。開発者としては、できるだけ手間をかけたくないのが本音でしょう。

一方で、近年の認証基盤にはセキュリティ強化やUX向上のため多くの機能が求められるようになってきています。

SMSやTOTPを用いたMFA（多要素認証）、GoogleやFacebookなどのソーシャルアカウント連携、SAML/OIDCによるSSO（シングルサインオン）など。 なお、SSOは「認証済みセッションを複数サービスで共有する仕組み」であり、SAML/OIDCはそのためのフェデレーションを実現するプロトコルです。

これらを実装・運用するには多大な労力がかかり、肝心のビジネスロジックに注力しづらい——そんな悩みはありませんか？

そのお悩み、IDaaSが解決してくれるかもしれません。

IDaaSとは

IDaaSとはIdentity as a Serviceの略で、IaaS (Infrastructure as a Service) やSaaS (Software as a Service) などのXaaSの一種です。 IDaaSを説明する前に、認証・認可を簡単に整理しておきます。

  • 認証
    • 「アプリケーションを使うユーザーが誰か？」を確認すること
    • 本人からのリクエストであることを検証し、第三者からのアクセスをブロックする
    • 身分証明書を見せて、本人であることを確認してもらうようなもの
  • 認可
    • 「そのユーザーがどのような操作を行えるか？」を判定すること
    • 予め定義されたスコープ（役割など）に応じて権限が与えられ、権限が与えられていない操作は拒否される
    • 身分が証明された後、その役割（例：管理者、一般ユーザー）に応じて、特定の部屋への入室許可をもらうようなもの

例えば Amazon のようなショッピングサイトであれば、商品を購入するにはユーザーの登録とログインが必要です。（認証） ログインしたユーザーは、自分のカートの中身は見れますが、他のユーザーのカートの中身は見れません。（認可）

これらの機能をまとめてIAM (Identity and Access Management) と表現したりもします。

IDaaSは、上述したユーザーの認証・認可にまつわる機能をクラウドサービスとして提供します。 開発者はIDaaSが提供するSDKやAPIを使用することで、インフラを構築したり、コードを書いたりすることなく認証・認可を実装することができます。

ただ、一口にIDaaSと言っても数多くのサービスが存在し、提供する機能や強みは様々です。以下に代表的なIDaaSを挙げます。

代表的なIDaaSと提供機能の例

用途 サービスの例 提供する機能の例
EIAM
(従業員向け) 		Okta
Microsoft Entra ID（旧 Azure AD）
OneLogin 		・MFA（多要素認証）
・SSO（シングルサインオン）
・ディレクトリ統合
・ユーザーライフサイクル管理
・ガバナンス管理
CIAM
(顧客向け) 		Auth0
Firebase Authentication
Amazon Cognito 		・MFA（多要素認証）
・外部IdP連携（SAML/OIDC）
・ソーシャルアカウント連携
・パスワードレス認証
・ログイン画面のカスタマイズ

IDaaSの中でもEIAM (Enterprise Identity and Access Management) 向けの製品とCIAM (Customer Identity and Access Management) 向けの製品があります。

前者は主に企業の従業員IDの管理に利用されるもので、SSO機能に加えてセキュリティやガバナンスといった領域に力を入れた製品が多い印象です。 後者は主にアプリケーションを利用する顧客IDの管理に利用されるもので、開発者向けの機能が充実している製品が多い印象です。

注意：説明の便宜上このように用途を分けましたが、明確な区分けはされていません。あくまで参考程度にお考えください。

今回は、Webアプリケーション開発においてよく利用されるCIAM向けのIDaaSを使って、従来のフレームワークをベースとした認証・認可のうち認証処理を置き換えるケースについて説明します。

従来の認証基盤の構成例

LaravelやRailsといったフレームワークやライブラリを使用して認証を実装する場合、一般的には以下のようにログイン画面を提供するWebサーバー、ログインユーザーを検証するアプリケーショサーバー、ユーザー情報を登録するデータベースを自前で用意する構成になるかと思います。

従来の認証フロー（ログイン時）

  1. ユーザーがログインページにアクセスし、ログインフォームにユーザーID、パスワードを入力して送信
  2. 入力されたユーザーIDに紐づくユーザー情報をデータベースへ照会
  3. 該当するユーザーの情報をアプリケーションサーバーに返却
  4. データベースから返却されたユーザー情報をもとに、入力されたユーザーIDとパスワードが一致するか検証
  5. 4.の検証が成功したら、セッションまたはアクセストークンをユーザーに発行
  6. セッションIDまたはアクセストークンをCookieやヘッダーに追加し、アプリケーションのコンテンツ（APIなど）をリクエスト
  7. セッションまたはアクセストークンの検証に成功したら、コンテンツを返却

この構成では以下のような課題が発生します。

  • 実装負荷
    • ログイン画面の実装
    • 認証・認可ロジックの実装
    • MFA、フェデレーションなどの追加機能の実装
    • データベースの構築
  • 運用負荷
    • 認証基盤に必要な耐障害性・可用性を維持できるように設計・運用する必要あり
  • セキュリティの担保
    • 脆弱性対応
    • 認証ログの取得・保管

では、IDaaSの利用によって上記の課題がどのように解決されるかを見ていきましょう。

IDaaSへの置き換え

先ほど例を挙げたCIAM向けIDaaSは、ユーザー情報を管理・提供するデータベースであるIDプロバイダー（IdP）として機能します。 業界標準の認証プロトコルであるOpenID Connect、および、認可プロトコルであるOAuth 2.0に準拠しており、SDKも提供されているため、認証・認可処理のアプリケーション統合もスムーズに行えます。

また、Amazon Cognitoユーザープールのマネージドログインなど、IDaaSのサービスプロバイダーが既成のログインページをホストし、管理してくれる機能も提供されています。

例えばAmazon Cognitoとマネージドログインを使用し、OpenID Connectベースの認証基盤を構築した場合、以下のような構成になります。

Amazon Cognitoでの認証フロー（ログイン時）

  1. ユーザーがログインページにアクセスし、ログインフォームにユーザーID、パスワードを入力して送信
  2. 入力されたユーザーIDとパスワードが一致するかAmazon Cognito内部で検証
  3. 2.の検証が成功したら、認可コードとともにリダイレクトしたあと、トークンエンドポイントからアクセストークン（JWT）を発行
  4. アクセストークンをヘッダーに追加し、アプリケーションサーバーのコンテンツ（APIなど）をリクエスト
  5. Amazon CognitoからJWKを取得し、アクセストークンの署名を検証
  6. アクセストークンの検証に成功したら、コンテンツを返却

OpenID Connectの認証フローについては詳細を省略し、要点のみ記載しています。 このケースではCognitoユーザープールをIDプロバイダーとして利用していますが、OpenID Connect/SAMLを介して既存の外部IDプロバイダーと連携することも可能です。

従来の認証基盤の図から比べると、データベースが無くなり、Cognitoユーザープールへ置き換わっているのが分かると思います。 以下のように認証基盤の大部分をIDaaSに任せることができ、何よりセキュリティをIDaaSプロバイダー側が担保してくれるため、本来注力したいビジネスロジックの開発に専念できます。

  • 実装負荷
    • ログイン画面
      • IDaaSが提供するため、実装不要
      • 必要に応じてUIのカスタマイズも可能
    • 認証・認可ロジック
      • 認証ロジックはIDaaSが提供するため、実装不要
      • ただし、発行されるトークンに応じた認可ロジックに関しては実装が必要
    • MFA、フェデレーションなどの追加機能
      • IDaaSの機能として提供されるため、実装不要
      • 利用者側で機能の有効化・設定が必要
    • データベース
      • IDaaSに内包されるため、構築不要
  • 運用負荷
    • 耐障害性・可用性
      • IDaaSが担保
      • ただし、SLA (Service Level Agreement) は要確認
  • セキュリティの担保
    • 脆弱性対応
      • IDaaSが対応
    • 認証ログの取得・保管
      • IDaaSで取得・保管
      • 利用するIDaaSによっては、利用者側で別途設定が必要な場合もある

負荷軽減以外のメリットとして、データベースなどのサーバー管理が不要になるため、サーバーレスアーキテクチャとの親和性が高い点も挙げられます。

IDaaS利用にあたっての注意点

サービス選定

上述した通り、IDaaSには様々なサービスが存在し、機能も利用料も様々となっています。 そのため、後から「必要な機能がない！」「思っていたよりも料金が高い！」とならないよう、適切なサービスを選定することが重要となります。

加えて、環境との親和性についても考慮すべきです。例えばAWS上のアプリケーションであれば、AWSとの連携に強いAmazon Cognitoが有力な候補になるでしょう。

また、何でもかんでもIDaaSに置き換えればよい、というわけではありません。 IDプロバイダーの詳細なカスタマイズが必要、等の特殊な要件下では従来のフレームワークを利用した認証基盤の方が適したアーキテクチャとなる場合もあります。

「IDaaS利用によって何を実現したいか？」「本当にIDaaSの利用がベストか？」をよく考えて導入を決定しましょう。

セキュリティ

IDaaSが認証基盤のセキュリティを担保してくれるとはいえ、利用者側が何も考慮しなくていいわけではありません。 例えば、トークンの保管場所や有効期限の設定、バックエンドでのトークン検証の実装等については利用者側の責任となります。

サービスプロバイダーと利用者との責任分界点を意識し、利用者側の責任範囲に関しては従来通りセキュリティを考慮して設計するよう心がけましょう。

データ移行

既存システムからIDaaSへの移行では、パスワードハッシュの差異や属性マッピングといった技術的課題に加え、データレジデンシや個人情報保護法への準拠といった法規制面も考慮が必要です。 移行方式を検討し、リスク評価を十分に行った上で導入を進めることが重要です。

まとめ

本記事では、Webアプリケーションにおける認証基盤の課題を解決する手段として、IDaaSの活用について解説しました。

IDaaSを導入することで、MFAやソーシャルログインといった現代的な要求にも応えつつ、認証・認可に関わる実装・運用・セキュリティの負荷を大幅に軽減できます。 これにより、開発者は本来注力すべきビジネスロジックの開発にリソースを集中させることが可能になります。

一方で、IDaaSもまた銀の弾丸ではありません。サービス選定時には、「何を実現したいのか」という目的を明確にし、機能要件やコスト、既存システムとの親和性などを慎重に比較検討することが重要です。 また、IDaaSがセキュリティを担保してくれるとはいえ、トークンの保管やバックエンドでの検証実装など、利用者側の責任範囲については従来通りセキュリティを考慮した設計が必要です。

さらに、既存システムからの移行を検討する際は、ユーザーデータの移行計画や、データ所在・法規制への準拠も含めて総合的に判断することが求められます。

この記事が、認証基盤の構築や運用に悩む方々にとって、IDaaSという選択肢を適切に検討するための参考となれば幸いです。

参考