このセクションでは、CloudGearが提供する認証サービスと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 Core 1.0 incorporating errata set 1

Authorization Code Flow

CloudGearが採用しているOpenID ConnectのAuthorization Code Flowを以下に示します。

番号	説明
①	ユーザーがアプリケーションにアクセスした際に、アプリケーションにセッション情報がない場合、認証処理が開始します。アプリケーションは、CloudGear（OP）に対して認可コードを要求します。認可コードの要求に対してCloudGearは、OP上にユーザーのセッション情報があるかを確認します。ユーザーのセッション情報がある場合、ログイン処理は発生せず、②の処理に遷移します。 CloudGearは、ユーザーにログイン画面を返却し、ログインがなされた場合、アプリケーションに対して認可コードを返却します。
②	アプリケーションは、①にて返却された認可コードを利用して、CloudGearに対してアクセストークンを要求します。このアクセストークンのスコープは、以下の4つになります。 openid：ユーザーの認証情報を要求 profile：ユーザー情報へのアクセスを要求 email：ユーザーのメールアドレスを要求 offline_access：リフレッシュトークンの返却を要求この要求によりCloudGearは、アプリケーションに対して上記権限を要求できるアクセストークンとIDトークンを返却します。 IDトークンを解析することでアプリケーションは、セッション情報を取得・生成することができます。（認証の完了）
③	アプリケーションは、②にて返却されたアクセストークンを利用して、CloudGearに対してユーザーの属性情報を要求することができます。ユーザー属性が不要な場合は、この処理を省くことができます。

番号

説明

①

ユーザーがアプリケーションにアクセスした際に、アプリケーションにセッション情報がない場合、認証処理が開始します。

アプリケーションは、CloudGear（OP）に対して認可コードを要求します。
認可コードの要求に対してCloudGearは、OP上にユーザーのセッション情報があるかを確認します。

ユーザーのセッション情報がある場合、ログイン処理は発生せず、②の処理に遷移します。

CloudGearは、ユーザーにログイン画面を返却し、ログインがなされた場合、アプリケーションに対して認可コードを返却します。

②

アプリケーションは、①にて返却された認可コードを利用して、CloudGearに対してアクセストークンを要求します。

このアクセストークンのスコープは、以下の4つになります。

openid：ユーザーの認証情報を要求
profile：ユーザー情報へのアクセスを要求
email：ユーザーのメールアドレスを要求
offline_access：リフレッシュトークンの返却を要求

この要求によりCloudGearは、アプリケーションに対して上記権限を要求できるアクセストークンとIDトークンを返却します。

IDトークンを解析することでアプリケーションは、セッション情報を取得・生成することができます。（認証の完了）

③

アプリケーションは、②にて返却されたアクセストークンを利用して、CloudGearに対してユーザーの属性情報を要求することができます。

ユーザー属性が不要な場合は、この処理を省くことができます。

概要

OpenID Connectとは

Authorization Code Flow

実装例

Relying Party実装

サービスにシングルログアウトを実装する

ログイン画面をカスタマイズする