このセクションでは、CloudGearが提供する認証サービスとCloudGearアプリケーションが連携するために必要なアプリケーション側の設定・実装に関して説明します。
概要
CloudGearでは、認証サービスとしてOpenID Connect（ https://openid.net/specs/openid-connect-core-1_0.html ）に準拠したOpenID Connectプロバイダー（以下、OP）を提供しています。
CloudGearアプリケーションは、Relying Party（以下、RP）としての実装を施し、CloudGearのOPを参照するように設定することで、ユーザー認証を一元化することができるようになります。
ここでは、OpenID Connectの説明とRPの具体的な実装例について解説します。
OpenID Connectとは
OpenID Connectは、ユーザーがパーソナルデータのコントロールを行うことを目的とした認証プロトコルです。
Webサービスごとにアイデンティティを使い分けて、利用者のプライバシー強化を実現する技術として標準化が進められてきました。
既存のOpenID（以下、OpenID 1.0）では、単一のユーザーIDを用いて広く一般に活用できる基盤・プロトコルの確立を目指して、起案されてきました。
その多くの部分において目的は達成されていましたが、認証を行う上でセキュリティ上の不安を抱えています。
一方で、アプリケーションの連携手法の一つとしてOAuth 2.0が挙げられます。
OAuth 2.0は、簡易的でかつセキュアなフローを用いる連携手法のため多くのサービスやアプリケーションにおいて認証の代替として利用されてきました。
しかしながら、OAuth 2.0は認可を行うプロトコルのため認証の代替として利用することは不適切であり、ユーザーが持つ属性情報をアプリケーションが広く活用することには適しておりません。
OpenID Connectは、これら2つの要素を組み合わせた仕様であり、OpenID 1.0における単一のユーザーIDを複数のアプリケーションで活用するという理念とOAuth 2.0のセキュアなフロー管理を組み合わせた仕様になります。
OAuth 2.0のフローを拡張し、認証をも内包する仕様として拡張定義されたものをOpenID Connectと呼びます。
CloudGearの認証では、OpenID ConnectにおけるAuthorization Code Flowを採用しています。
具体的な流れに関しては、以下をご確認ください。
OpenID Connectの詳細な仕様に関しましては、こちらをご確認ください。
Authorization Code Flow
CloudGearが採用しているOpenID ConnectのAuthorization Code Flowを以下に示します。
| フロー番号 | 説明 |
|---|---|
| ① | ユーザーがアプリケーションにアクセスした際に、アプリケーションにセッション情報がない場合、認証処理が開始します。 アプリケーションは、CloudGear（OP）に対して認可コードを要求します。 ユーザーのセッション情報がある場合、ログイン処理は発生せず、②の処理に遷移します。 CloudGearは、ユーザーにログイン画面を返却し、ログインがなされた場合、アプリケーションに対して認可コードを返却します。 |
| ② | アプリケーションは、①にて返却された認可コードを利用して、CloudGearに対してアクセストークンを要求します。 このアクセストークンのスコープは、以下の4つになります。
この要求によりCloudGearは、アプリケーションに対して上記権限を要求できるアクセストークンとIDトークンを返却します。 IDトークンを解析することでアプリケーションは、セッション情報を取得・生成することができます。（認証の完了） |
| ③ | アプリケーションは、②にて返却されたアクセストークンを利用して、CloudGearに対してユーザーの属性情報を要求することができます。 ユーザー属性が不要な場合は、この処理を省くことができます。 |
