HPE Blog, Japan
1821999 メンバー
3500 オンライン
109639 解決策
新規ポスト
IceWall_Mktg

次世代のフェデレーション方式 OpenID Connect

HPEの認証・アクセス管理ソリューション「HPE IceWall」を開発するIceWallビジネス推進部が、認証を知る上で必要な基礎知識やトレンドを深掘りするブログです。

GettyImages-1031567882_1600_0_72_RGBs.jpg

 

前回の投稿では、クラウドフェデレーションの基本的な考え方と、SAML方式(SAML2.0)の紹介をいたしました。
今回は業界標準として新しく規定され、SAMLと並んで使用されている OpenID Connect(以下、OIDC)の紹介を中心にお話しします。

 

なぜ2つのフェデレーション方式が必要になったのか

SAMLは企業をまたいでIDと業務アプリを連携させるフェデレーションのために、XMLの技術を活用してベンダー中立の標準仕様として作成されました。
比較的単調で固定的なフェデレーション処理においては、SAMLは必要十分な能力を発揮してきましたし、それは今も変わりません。

SAMLでは、単純なIdPとSPの関係、つまりある企業の従業員がブラウザを使用し自社(IdP)のIDを使用して、外部組織やパブリッククラウドの業務サービス(SP)を利用するという、ユースケースがもっぱら使われてきました。
SAMLは業界標準として厳密に定義されているため、幅広い業務サービスとのID連携を可能としてきました。

icewall221128-01.jpg

図1 OIDCによるSSO

 

その後、インターネット上でのアプリケーション活用の要件が、単純なIdP/SPの関係から、API連携やSNSアカウントを利用したID連携など、フェデレーション技術が活用される領域・ニーズが大きく広がってきました。

 

広がるフェデレーションのユースケース

個人ユーザーが、GoogleやFacebookやYahoo!JAPANのソーシャルサイトのアカウント情報を使用して、それ以外の種々のサービス、例えば食べログ、Twitter、はてなブログやメルカリなどにログインする際、前者のIDさえ作成しておけば後者のサービス側では新たなIDとパスワードを作成しなくてよい、というフェデレーションを日常的に見かけるようになりました。
これをソーシャルログインと呼びます。

ログインする時に、ソーシャルサービス側が持つ個人ユーザー属性情報のうち、どの情報をサービス側に連携するのかが表示されたり、場合によってはどの属性情報を連携してよいかをユーザー本人が選ぶことができるようになっている画面を見たことがある方も多いでしょう。
これは、個人ユーザーの属性情報や、個人ユーザーがサービス内に保持しているデータを、その個人が認可した時に初めて相手サービスに連携できるようなOIDCの仕組みが提供されているためです(同意機能)。
SAMLでは、このようなユーザー毎の個別確認はできません。

icewall221128-02.jpg

図2 ソーシャルログインと同意確認の例

 

ユーザーが利用するサービスやアプリに目を移してみると、スマホアプリがユーザーの生活の中心となり、JavaScriptを使用してブラウザ上のみで実装されるようなアプリも多くなり、それらユーザー端末上のアプリも認証処理を必要とします。
OIDCはこのようなユースケースに対して、アプリのログイン処理のみに限定した機能を、シンプルなやり取りで実装可能な方式で提供しています(インプリシットフロー、Implicitフロー)。

クラウドフェデレーションを用いて商取引や金融取引などを行う業務は、攻撃者の格好のターゲットになります。
フェデレーション処理の結果としてやり取りされる認可コードを何らかの方法で傍受されたりアタックされたとしても、業務への侵入は行えないようにする仕組みが必要となります。
OIDCはこのような攻撃からサービスを守るために、OPとRPがお互い正しい相手かどうかを検証できるようにするための仕組みも提供しています(PKCE;Proof Key for Code Exchange)。

 

最近は、インターネット上の異なる企業のサービス同士を連携させて、新たな価値を提供するサービスも台頭しています。
また個人ユーザーに対するサービスであっても、サーバー上のサービスがユーザーを代行して他のサービスと連携して価値を提供するようなものもあります。
このケースでは業務サービス同士をAPI接続することで連携しますが、OIDCはAPIアクセスに適した認証の仕組みを提供しています。(認可コードフロー、Authorization Codeフロー)。

icewall221128-03.jpg

図3 OIDCによるAPIサーバー利用フロー

 

今後もOIDCとSAMLの併用は続きます

このように多様なニーズがフェデレーション認証に求められるようになってきました。
OIDCはこれらのユースケースへの対応を業界標準として提供し、業界のニーズに即した新しい機能を追加していく活動を継続しています。
OIDCはゼロトラストの中で、多様な接続形態や利用形態を可能にしていくでしょう。

一方でSAMLはOIDCに比べて歴史があり枯れて安定した技術のため、すでに多くのサービスで実装され、今も活用されています。
企業のユーザーIDを契約のある外部クラウドサービスの認証に使用することや、SASEのようなゼロトラストの新しい仕組みの中でユーザー認証を行う、といった純粋なSSOのユースケースでは、引き続きSAMLが利用されています。


企業の認証基盤を種々のサービスにまで広げて活用することを可能にするフェデレーションは、ゼロトラストの中でもますます重要性が高まっていきます。

 

[関連リンク]
本シリーズ第1回:ゼロトラストに取り組む上で欠かせない「認証」を考える
本シリーズ第2回:普及が進む多要素認証 - FIDO2と生体認証
本シリーズ第3回:ゼロトラストにおいても重要なクラウドフェデレーション


HPE IceWall 製品公式サイト(https://www.hpe.com/jp/icewall)
クラウド認証連携ソリューション HPE IceWall Federation

0 感謝
作者について

IceWall_Mktg

コラム:氷壁エキスパートノート |  HPEの認証・認可プラットフォーム「HPE IceWall」を開発するIceWallビジネス推進部が、認証にまつわる新常識を発信します。