シングルサインオンを実現する際に利用する「SAML」「OIDC」「OAuth」プロトコルとは？

近年、クラウドサービスは急速に普及し、その利用は経営において不可欠な要素となりました。企業が成功するためには、優れたクラウドサービスを素早く導入する能力が重要です。

一方で、企業がクラウドサービスを活用して顧客にサービスを提供する場合、顧客は各サービスごとに異なるログインIDとパスワードを覚える必要があり、これが企業にとって重大な課題となっています。

この記事では、1回のログイン操作で複数のサービスにアクセスできるシングルサインオンを実現するための方法の1つであるフェデレーション方式と、代表的な認証プロトコルであるSAML、OIDCと、認可プロトコルであるOAuthについて詳しく紹介します。

---

シングルサインオンを実現するためには、いくつかの方法があります。それらの方法には、フェデレーション方式、エージェント方式、リバースプロキシ方式、代理認証方式などが含まれます。

シングルサインオンは、異なるサービス間でログイン情報を共有し、1回のログインで複数のサービスにアクセスできる仕組みを提供しますが、フェデレーション方式は、主に異なるクラウドサービスやシステム間でアイデンティティ情報を安全に共有するために使用されます。

フェデレーション方式の中でも、異なるクラウドサービスやシステム間でアイデンティティ情報を安全に共有するために、標準化された手順が提供されています。標準化された手順をプロトコルと呼びますが、代表的なプロトコルが、SAML、OIDCといったものです。

標準化された手順であるSAML、OIDCを利用することで、サービス間での互換性を担保しつつ、アイデンティティ情報が安全に共有されます。

※なお、本記事では、シングルサインオンを実現する際に利用されるOAuthプロトコルを紹介していますが、OAuthはログイン情報を受け渡すプロトコルではなく、代わりにアクセス権限を管理するためのプロトコルです。そのため、OAuthはフェデレーション方式のプロトコルではありません。

---

シングルサインオンを実現するうえでは、認証と認可について正しく理解しておく必要があります。

認証

認証とは、ログインしようとしているユーザーが、本当に本人であるか確認するプロセスです。

例えば、ECサイトのマイページへログインする場合、ユーザーIDとパスワードの入力を求められたとします。この場合、入力されたユーザーIDで誰かを特定し、入力されたパスワードで本当に本人であるか確認を行います。パスワードは基本的に本人しか知り得ない情報となるため、本当に本人であるか確認するプロセスで利用されます。

パスワード以外にも、指紋や顔の生体情報、ユーザーが保有しているスマホのSMSに送付されるコードなども認証のため本人しか知り得ない情報として利用されます。このような本人しか知りえない情報を総称して、クレデンシャルと言います。

認可

認可とは、ユーザーに代わってサーバーに保管されているデータへのアクセス許可、特定のサイトへのアクセス許可など、リソースやデータへのアクセス権限を管理するプロセスです。

例えば、有料会員のユーザーに有料会員専用サイトへのアクセス権を付与し、無料会員のユーザーにはそれが付与されないように管理されます。

シングルサインオンは、1度のログイン操作で複数のサービスにアクセスできる仕組みを広く指す言葉です。この仕組みにおいて、認証や認可は通常、ECサイトとは異なる外部の認証基盤で行われます。したがって、認証基盤とECサイトの間で認証情報や認可情報の受け渡しを行う必要が生じます。

この認証や認可情報の受け渡しを、互換性を担保しつつ安全に共有するために、標準化された手順であるSAML、OIDC、OAuthなどのプロトコルが広く利用されています。

---

SAMLとは、「Security Assertion Markup Language」の略称で、OASISという団体によって策定された認証のためのプロトコルです。IdP(アイデンティティプロバイダ)から、SP（サービスプロバイダ）へ認証情報を安全に共有するために使用されます。

IdPは認証情報を提供する側、SPは認証情報を受け取る側となりますので、シングルサインオンで利用する場合は、IdPはログインする際の認証基盤、SPはECサイトとなり、認証基盤及びECサイトの双方でSAMLに対応していることで、SAMLの手順に沿って認証情報が受け渡しされます。

IdPからSPへ認証情報を安全に共有するための仕組みとして、IdPがユーザーに対して認証画面を提示し、認証が成功するとIdPから認証情報がエンコードされたXMLフォーマットのセキュリティーアサーションを発行され、HTTPS経由でSP側へ共有されます。

セキュリティーアサーションは秘密鍵を使用して署名されているため、SPはIdPから事前に共有されている公開鍵を利用して、暗号化されたデータやメッセージを元の状態に戻すことで、認証情報が安全に共有されます。

---

OAuthは「Open Authorization」の略称で、共同で開発およびサポートされているオープンスタンダードである認可のための標準規格のひとつです。2007年にウェブサービスを対象としたOAuth1.0がリリースされた後、スマホアプリの普及に伴い、2012年にスマホアプリも対象としたOAuth2.0がリリースされています。

※OAuth1.0と2.0には互換性はなく、現在の主流はOAuth2.0です。

リソースやデータへアクセスする際に、悪意のあるアクセスを防いだり、ユーザーに応じて必要なリソースへアクセスする権利を与えたりといった、アクセス管理を行うために利用されています。

例えば、ECストアを運営中の企業担当者が、外部の分析ツールを利用してデータを分析する際に、企業担当者に代わって分析ツールがECストアのデータへアクセスする必要がありますが、安全にデータが受け渡されるようデータを渡してよいか権限の確認を行うためにOAuthが利用されています。

仕組みとしては、アプリケーションがリソースオーナーに対して、リソースサーバーへのアクセス許可を取得し、認可サーバーからアクセストークンと呼ばれるデータへのアクセス許可証を取得します。

アプリケーションは、アクセス許可証となるアクセストークンとセットで、リソースサーバーへデータへのアクセスリクエストを送ることで、リソースサーバーからアプリケーションへ安全にデータが受け渡されます。

例えば、eコマースプラットフォームの「Shopify」では、以下の図のようにShopifyがリソースサーバーと認可サーバーの役割を兼ねています。しかし、リソースサーバーはShopify、認可サーバーは別の認証プラットフォームで担うといったように認可サーバーとリソースサーバーの役割を担うシステムが異なる場合もあります。

引用元：Shopify developer documentation「OAuth overview」

シングルサインオンで利用する場合は、認証基盤とECサイト間で認証や認可情報の受け渡しをする必要があり、その中で OAuth は認可を扱うプロトコルとして、ユーザーのリソースに対するアクセス権限を付与するために使用されます。

しかし、OAuthを活用してSSOを実現するためには、認証の要素を組み込むための拡張が必要となります。OAuth 2.0をベースに認証を追加したプロトコルが、次にご紹介させて頂くOIDCです。

---

OIDCは「OpenID Connect」の略称で、アプリケーションがAPIへ認証情報を共有するための、認証の標準規格のひとつです。OAuth 2.0のフレームワークをベースに構築されているため、アクセストークンを利用したデータ共有の仕組みに加えて、認証情報を安全に共有するために利用されています。

そのため、OAuthにてご紹介したアクセストークンに加えて、OpenIDプロバイダから発行されたユーザーの認証情報が含まれるIDトークンの受け渡しを行うことで、認証情報が受け渡されます。

例えば、ユーザーがECサイトのマイページなどにアクセスし認証が必要な場合、ECサイトは認証基盤にリダイレクトし、認証が成功すると認証基盤はIDトークンを生成し、ユーザーのブラウザを介してECサイトにリダイレクトします。

生成されたIDトークンは認証基盤からECサイトにHTTPS経由で送信され、ECサイトは事前に共有された認証基盤の公開鍵を使用してIDトークンの署名の検証を行い、検証が終わるとIDトークンに含まれるユーザーの認証情報を使用して、ユーザーを認証しセッションを確立します。

---

シングルサインオンを実現する際の方式や、クラウドサービス間で互換性を保ちつつ安全に認証や認可情報を受け渡すためのSAML・OIDC・OAuthプロトコルについてご紹介させて頂きました。

上記のプロトコルを利用する場合は、認証・認可情報を渡す側と受け取る側がいずれも同一のプロトコルを採用していることが前提となりますが、サービスによってプロトコルに対応していない場合や、どのプロトコルを採用しているかが異なります。

例えば、ECストアのマイページへログインする際に、外部の認証基盤を利用してシングルサインオンを実現する場合、認証基盤でOIDCを採用していた場合でも、ECストア側で対応していない場合は、OIDCを利用したシングルサインオンを実現することができません。

弊社では、このようなECサイト側にシングルサインオン基盤がない場合のシングルサインオン基盤を提供しており、例えばeコマースプラットフォームのShopifyと認証基盤を繋ぐシングルサインオン基盤を提供しています。

その他にも、ソーシャルログインなどのID連携や、ECサイトのアカウントを利用したシングルサインオンを実現するためのIdPの提供、サイト間のポイント連携といったようなID＆データ連携や活用といったIDソリューションを幅広く展開及び展開していく予定です。

ID連携やデータ連携などに関してID統合・シングルサインオン周りでの課題がございましたら、ぜひ一度お話をお聞かせいただき、実現について一緒に考えさせてください。

◆ お問い合わせフォーム