なぜシングルサインオン (SSO) が優れているのか

シングルサインオン (SSO) は、ユーザーが一度認証すると複数のアプリケーションにアクセスできる技術です。もしあなたが一つのアプリケーションしか持っていない場合は、これは行き過ぎのように聞こえるかもしれません。しかし、最初からSSOを導入することは、後々多くの手間を省くことができ、SSOの実装は思ったより簡単です。

始める前に、SSOには2種類あることを確認する必要があります。

• 一つ目は、同じユーザーデータベースを共有する複数のアプリケーションを持っている場合です。この記事で取り上げるのはこのタイプのSSOです。
• 二つ目は、クライアントに中央集権化されたIDプロバイダー (IdP) があり、それと統合する必要がある場合です。この記事の範囲外です。

なぜSSO？#

認証モデルを簡素化#

SSOの最も明らかな利点は、認証モデルを簡素化することです。例えば、あなたがオンラインストアを始めたとき、最初の認証モデルはシンプルです:

ビジネスが成長するにつれて、あなたは店舗管理アプリを追加し、ストアオーナーが店を管理できるようにすることを決定します。今、ユーザーを認証する必要がある2つのアプリケーションがあります。

ここにいくつかの選択肢があります:

1. 店舗管理アプリ用の別のユーザーデータベースを作成する。

これは最も単純な解決策ですが、店舗管理アプリの認証プロセスを実装する必要があり、ユーザーはアプリを使用するために新しいアカウントを作成しなければなりません。

2. 両方のアプリケーションで同じユーザーデータベースを使用する。

これはより良い解決策です。ユーザーは新しいアカウントを作成する必要がありません。しかし、あなたはまだ店舗管理アプリの認証プロセスを実装する必要があります。

3. SSOを使用する。

これはこれまでのところ最良の解決策です。別の認証プロセスを実装する必要がなく、ユーザーは店舗管理アプリのために新しいアカウントを作成する必要がありません。さらに、認証モデルやユーザーエクスペリエンスを変更することなく、より多くのアプリケーションやサインイン方法を追加できます。

ユーザーエクスペリエンスの向上#

SSOは2つの方法でユーザーエクスペリエンスを向上させます:

• ユーザーは複数のアプリケーションで同じアカウントを共有できます。
• 一つのアプリケーションでサインインすると、同じデバイス上の他のアプリケーションで再びサインインする必要がありません。

いくつかの懸念が生じるかもしれませんが、それらはすべて解決可能です。

1. アプリケーションをどのように区別しますか？

シングルサインオンはすべてのアプリケーションを同じように扱うことを意味するわけではありません。有名なオープンスタンダード OpenID Connect では、各アプリケーションはクライアントと呼ばれ、認証フローはクライアントの種類に応じて異なります。エンドユーザーは違いを知る必要はありませんが、認証サーバが認証フローを決定するためにクライアントの種類は重要です。

2. もしユーザーが同じアカウントを共有したくない場合はどうしますか？

これは有効な懸念ですが、それはSSOの問題ではありません。ユーザーが同じアカウントを共有したくない場合、新しいアプリケーション用に新しいアカウントを作成することができます。重要なのは、ユーザーに選択の余地を与えることです。

3. 特定のアプリケーションへのアクセスを制限する必要がありますか？

実際には、SSOは認証の技術であり、アクセス制御は認可のためのものです。SSOをアクセス制御から切り離すことができます。例えば、SSOを使用してユーザーを認証した後、ロールベースアクセス制御 (RBAC) を使用して特定のアプリケーションやリソースへのアクセスを制限することができます。

認証と認可について詳しく知りたい方は、CIAM 101: Authentication, Identity, SSOをご覧ください。

4. SSOはユーザーを認証サーバにリダイレクトする必要があります。

リダイレクトは認証の標準的な手法です。ユーザーエクスペリエンスを考慮して、複数の技術を活用して摩擦を減らすことができます:

• 認証の頻度を減らすためにリフレッシュトークンを使用します。
• 特定のサインイン方法（GoogleやFacebookなど）で認証プロセスを開始してクリック数を減らします。
• サイレント認証を活用して認証プロセスを迅速化します。

セキュリティの強化#

1. すべてのセキュリティ関連の操作を管理するための中央の場所

SSOでは、すべてのセキュリティ関連の操作を中央で管理できます。例えば、前のセクションで述べたように、SSOはアプリケーションを区別し、各アプリケーションにプラットフォーム固有の認証フローを適用することができます。SSOがなければ、アプリケーションタイプに応じて様々な認証フローを実装する必要があります。

さらに、多要素認証 (MFA) のような高度なセキュリティ機能は、SSOで認証モデルを混乱させることなく実装が容易です。

2. 攻撃面の縮小

理論的には、SSOは攻撃面を縮小します。なぜなら、複数のアプリケーションではなく一つの認証サーバだけを保護する必要があるからです。また、中央集権的なアプローチにより、疑わしい活動を監視しやすくなります。

3. 実績のある標準とプロトコル

OpenID Connect や OAuth 2.0 などのオープンスタンダードとプロトコルは、業界で広く使用され、長年にわたって実績が証明されています。これらはSSOのコンセプトと一致しており、ほとんどのIdPでサポートされています。これらの標準をSSOと組み合わせることで、安全で信頼性のある認証システムを構築できます。

よし、SSOを実装しよう#

SSOの実装は大きく複雑で、多くのことを考慮する必要がありますが、以下のような:

• 標準とプロトコルへの準拠
• 異なるクライアントタイプに対応する認証フロー
• 複数のサインイン方法
• MFAのようなセキュリティ機能
• ユーザーエクスペリエンス
• アクセス制御

これらのトピックはそれぞれ個別の記事として詳しく扱うことができ、小規模化されます。簡素化のためには、SSOをすぐに提供する管理されたサービスを使用するのが良いでしょう。私たちの製品 Logto はそのようなサービスであり、あなたのアプリケーションに数分で統合することができます。

管理されたサービスを使用する際の最も一般的な懸念の一つは、ベンダーロックインです。幸いなことに、これはLogtoの問題ではありません。LogtoはOpenID ConnectとOAuth 2.0の上に構築されており、オープンソースとして誕生しました。私たちはお客様に保証を提供することを優先し、選択の自由を持たせることを目指しています。