公開日:2007年6月28日
独立行政法人情報処理推進機構
セキュリティセンター
本ページの情報は2007年6月時点のものです。
記載の資料は資料公開当時のもので、現在は公開されていないものも含みます。
複数のWebアプリケーションがユーザ認証の機能を外部に一元化することによって、ユーザがパスワードを覚える負担を低減することができる。また、Webアプリケーションのオーナは、パーソナル情報の管理の負担とリスクを外部に転嫁することができる。
パスワードを用いたユーザ認証機能として、Webアプリケーションから利用可能な外部サービスが、2005年頃から提供されるようになってきた。
ユーザによるアクセス要求を遮断できるコードを開発して、そこから外部のユーザ認証サービスとアクセス認可判定の処理を順に呼び出すようにする。この要求を遮断できるコードは、PEP(Policy Enforcement Point)の役割を果たす。
ユーザ認証の結果をPEPに伝達するしくみとしては、「HTTPリダイレクト」の機能が応用されているものが多い。
複数のサイトが共通のユーザ認証サービスを利用する構図を示す。
ユーザ側には下記のメリットがある。
Webアプリケーションのオーナ側には下記のメリットがある。
外部のユーザ認証サービスとして OpenID Connect によるサービスを利用することができる。基本的な「認可コードフロー(Authorization code flow)」の場合の構図を示す。
ユーザ認証は「認可Endpoint」において行われる。そのユーザ認証の結果を伝達するにあたり、まずOpenID Connectプロバイダは「認可コード」を生成する。(注: ユーザ認証を行うにもかかわらず「認可Endpoint」と呼ばれる理由は、ベースとなったプロトコル(OAuth 2.0)の仕様に起因する。)
Webアプリケーションは認可コードを「トークンEndpoint」に送信する。同時にWebアプリケーションから「トークンEndpoint」宛には「Client Secret」が送られ、そのWebアプリケーションが本物であることが伝えられる。OpenID Connectプロバイダは、認可コードを「IDトークン」と交換し、Webアプリケーションにユーザ認証の結果を渡す。
「IDトークン」のフォーマットとしては JWT(JSON Web Token)仕様が使われる。JWT仕様は、デジタル署名や暗号化による防護機能を提供している。
「アクセストークン」も、Webアプリケーションに渡る。これは、ユーザ認証を行ったOpenID Connect プロバイダに対して、ユーザについての属性情報を取得する際に使われる。例えば、今回ユーザ認証が成功したユーザについての追加的な属性情報を求めてアクセス認可に利用することができる。追加的な属性情報の利用可能性は、OpenID Connectプロバイダがサポートしているスコープに拠ることになる。
参考資料: