シングルサインオン (SSO) とは、複数のアプリケーションで同じ認証セッションを使用することで、認証情報の入力を繰り返さずに済むアイデンティティソリューションのことです。SSO の実装は、重要なリソースへのアクセスを保護する戦略の一環として、世界中の企業に多く取り入れられています。クラウドコンピューティングの誕生や SaaS（サービスとしてのソフトウェア） の急成長に伴い、世界中の企業が、以前にも増して、セキュリティおよびユーザー体験の両方を強化することができるアクセス管理戦略に重点的に取り組んでいます。SSO の実装は、この両側面を達成することができます。

セキュリティ面で、Single-Sign Onがもたらすメリットは、複数のサービスへのサインインに求められる認証情報の数を1つに減らすことができ、紛失や盗難に遭う認証情報を少なくできる点です。さらに、 多要素認証（MFA）、または二要素認証（2fA）は、1つとなった強力な認証情報を守るよう義務付けられる可能性が高くなります。

エンドユーザーの立場からは、ID プロバイダー（IdP）の SSO 対応システムを活用することにより、認証情報入力の煩わしさを大幅に軽減でき、ユーザー体験が向上します。加えて、SSO を使用することで、何十にもなり得るアカウントの認証情報を覚えておくという負担から解消されます。

SSO ソリューションの導入はさらにうれしいことに、パスワードリセット操作に関する、ヘルプデスクへのコール数も削減できます。

通常、シングルサインオンの実装は、ユーザーがログインする時にアプリケーションが依存する、中央サービスの定義づけで構成されています。このアプローチでは、未認証のユーザーが ID 情報を求めるアプリケーションにリクエストすると、そのアプリケーションはユーザーを中央サービスにリダイレクトします。このサーバー上でユーザーは認証を行い、ID 情報とともに元のアプリケーションにリダイレクトされます。それにより、ユーザーは先に進めることができ、認証リクエストがトリガーされた時点でやりたかった作業を実行できます。

しばらくして、同じユーザーが、同様に ID 情報を要求し、ユーザー認証の実行を行う、同じ中央サービスに依存している別のアプリケーションを使用すると、この2つ目のアプリケーションは、最初のアプリケーションにサインインしている間は、ユーザーが開始したセッションを利用することができます。Google とそのさまざまなサービスが、

SSO の仕組みを明確に示すよい例です、たとえば、認証されないまま Gmail にアクセスしようとすると、Google は、「accounts.google.com」にホストされている中央サービスにリダイレクトします。すると、自分のユーザー認証情報を入力しなければならないサインインフォームが表示されます。認証がうまく処理されると、Google は Gmail にリダイレクトし、そこから自分のメールアカウントにアクセスすることができます。この中央サービスを介して認証した後に、他のサービスに移動する場合は（例：Youtube）、自動的にサインインされていることがわかります。

次の略図は、SSO の認証処理の仕組みについて詳しく示したものです。

ユーザーが「domain1.com」にアクセスしたいと想定した場合、このドメインを閲覧するとすぐ、認証サーバー「domain3.com」にリダイレクトされ、そこで認証を行います。認証がうまくいくと、「domain3」は、SSO レコードに使われるセッションクッキーを保存します。そして、 後に「domain1.com」が「domain1」のサービスにアクセスするための、ユーザー ID の証明に使われるトークンに交換できるアーティファクトとともに、ブラウザーを「domain1」にリダイレクトします。

（同じセッション内の）ユーザーが「domain2.com」にアクセスすると、「domain2」は、「domain3」にリダイレクトし、認証を行います。ただし、「domain3」は、ユーザーには（クッキー経由で）ログインセッションがあるという記録があるため、ユーザーにインタラクティブにログインするようには要求せず、代わりに以前のように適切な認証アーティファクトとともにブラウザーを「domain2.com」にリダイレクトします。.

SSO セッションの有効期間は、認証サーバー（domain3）によって決定されます。単純にブラウザーのセッションが続く限り存在するか、あるいは、セキュリティポリシーおよびユーザー体験の要件に基づいて、何時間または何週間かの一定期間存在することになります。

これが、Google やその他のサービスに使われている SSO の本質です。認証サーバーとクライアントアプリケーションの間のプロトコルは、通常、SAML 2.0、OpenID Connect、Kerberos または SSO に対応しているその他の認証プロトコルです。

他の多数の認証の場合と同じように、 シングルサインオンを実装する Auth0 を利用すれば非常に簡単です。アプリケーションの保護にすでに Auth0 を利用している場合、SSO は自動的に利用できます。たとえば、同じ Auth0 アカウントを使っているアプリケーションが2つ以上ある場合、1つのアプリケーションにサインインしていると、もう1つのアプリケーションにも意識せずにサインインしていることに気づきます。SSO セッションを活用するためにこれらのアプリケーションに特別なことをする必要はありません。

アプリケーションでシングルサインオンを有効化するために Auth0 を使用するその他の有用な点は、1か所でリソースへのアクセスの制御を行うことで、IT リソースの需要を減らすことができることです。

Auth0 について、また、Auth0 がシングルサインオンを実装するのにどのように役立つのか、Auth0 でアプリを保護する方法について、より詳しく知りたい場合は、docsを参照してください。

[IAM 入門ページ]（https://auth0.com/intro-to-iam/）で、さらに多くの、ID とアクセスの管理に関するトピックをご覧ください。