シングルサインオンとは何か？多くのアプリに1つのログイン

シングルサインオンを使うと、ユーザーは中央のアイデンティティプロバイダーで一度認証するだけで、再度ログインすることなく接続された多くのアプリケーションにアクセスできます。

シングルサインオン、すなわちSSOは認証を一元化します。ツールごとに別々のパスワードを持つ代わりに、ユーザーはアイデンティティプロバイダーに一度ログインし、そのプロバイダーが接続された各アプリケーションに対してユーザーを保証します。エンジニアリングチームにとって、SSOはGitHub、クラウドコンソール、CI/CDプラットフォームへのアクセスを1か所で統合・制御する方法です。

SSOの仕組み

中央のアイデンティティプロバイダー（IdP）がユーザーを認証します。ユーザーがアプリケーションを訪れると、アプリケーションはIdPにリダイレクトし、IdPはユーザーがすでにログイン済みであることを確認して、署名されたアサーションまたはトークンを発行します。アプリケーションはそのアサーションを信頼し、2つ目のパスワードなしでアクセスを許可します。

その背後にあるプロトコル

SAML: XMLベースのアサーションで、エンタープライズのWebアプリで一般的。
OpenID Connect: OAuth 2.0の上に構築された最新のアイデンティティレイヤー。
これらの標準により、IdPとアプリケーションは安全に相互に信頼できます。

チームがSSOを採用する理由

SSOはパスワードの乱立を減らし、オフボーディングを一元化し（1つのアカウントを無効化すればすべてへのアクセスが遮断される）、必須の多要素認証のような一貫したポリシーを可能にします。セキュリティチームにとっては、単一で監査可能な制御ポイントです。

SSOとCI/CDへのアクセス

CI/CDプラットフォーム、ソースホスト、クラウドアカウントへのアクセスは、しばしばSSOによって制御されます。これは人間向けのアクセスであり、パイプラインがサービスに対して認証する方法とは異なります。後者はインタラクティブなログインではなくトークンとOIDCを使います。

理解すべきリスク

SSOはリスクを集中させます。IdPの侵害は、その背後にあるすべてを露出させかねません。だからこそIdPアカウントには強力な多要素認証が求められ、セッションの有効期間や再認証ポリシーが非常に重要になります。

Latchkeyの観点

Latchkeyのようなツールへのプラットフォームアクセスは、通常、ソースホストとSSOを通じて統制されます。一方、runnerやサービスへのパイプライン認証は、インタラクティブなサインオンではなく、スコープされた短命の認証情報を使います。

重要なポイント

SSOを使うと、ユーザーは中央のIdPを通じて一度認証するだけで多くのアプリケーションに到達できます。
一般にSAMLまたはOpenID Connectの上で動作し、アクセスガバナンスを簡素化します。
リスクを一元化するため、アイデンティティプロバイダーは強力に保護されなければなりません。