OIDCプロトコルの概要と最新動向、および拡張仕様

現代のウェブサービスにおいて、GoogleやFacebookのアカウントで他のサービスにログインする機能は当たり前になりました。これを可能にしているのが、OpenID Connect (OIDC)というプロトコルです。OIDCは、単なる認可プロトコルであるOAuth 2.0を拡張し、安全な認証機能を追加したもので、シングルサインオン (SSO) の基盤として広く利用されています。

認証・認可に関する標準プロトコル

認証・認可に関するプロトコルには、主にOAuth 2.0、OpenID Connect (以下、OIDC)があります。これらは、特定の技術や企業に依存せず、広く普及している技術であり、我々が普段利用するインターネットサービスで広く利用されています。

OIDCの概念

Oauth2.0からの変化

Oauth2.0は認可を与える仕組みであり、あるアプリケーションを利用した場合にクライアントから認可サーバで認証を完了させるとトークンを発行し、アプリケーションを利用することが出来る便利な仕組みです。ただ、Oauth2.0では認証機能がなく、認証が必要な場合はOauth2.0だけでは対応できません。そのため、認証機能を提供するOIDCが利用されるようになりました。OIDCは、認可に特化したOAuth 2.0をユーザの認証にも使えるように拡張したものです。

OIDCによる改善

OIDCは、Oauth2.0の課題を解決するためにOAuth 2.0をベースに以下のような変更がされた規格となります。

IDトークンの導入: OIDCでは、認可サーバがアクセストークンに加えて、IDトークンを発行します。このIDトークンは、ユーザが確かに認証されたことを証明するもので、ユーザのIDや氏名、メールアドレスなどの基本情報を含んでいます。このトークンはJWT（JSON Web Token）形式で、改ざんを防ぐための署名が施されています。
スコープの追加: OAuth 2.0ではサービスの利用範囲に限りAccessTokenが作成されましたが、OIDCではユーザ認証追加したOpenidを作成し、ユーザに提供します。これにより、サービスプロバイダは認可サーバに対して、単なるリソースへのアクセス許可だけでなく、ユーザの認証も同時に要求できるようになりました。これらの変更により、OIDCは、OAuth 2.0が持つ「認可」の強みを活かしつつ、安全かつ効率的な「認証」を実現できるようになりました。

OIDC認証フローについて

下記のようなフローで認証が実施されます。ユーザ発信でRPに対してログイン要求が実施されると、RPからOPに対して認可リクエストが発生し、ログイン画面が返却されます。その後ID、PWでログインを実施すると認可コードがユーザに返却、認可コードをRPへリダイレクトし、RPからトークンをOPへリクエストされます。その後IDトークンをRPでの検証が成功すればログインが可能となります。

用語説明
RP（Relying Party）:
ユーザの認証結果（IDトークン）を信頼し、それを受け取ってユーザをログインさせるサービスの提供者
OP（OpenID Provider）:ユーザの認証情報を管理し、IDトークンを発行する

図1:OIDC認証フロー

OIDCの最新動向・拡張仕様

OIDCは認証のプロセスのセキュリティを高めたり、UXを改善する等の仕様見直しが実施されています。この記事ではOIDCの最新動向について説明します。

PKECの必須化

認可コードフローにおいて、PKCE（Proof Key for Code Exchange）という仕組みが必須化されてきています。PKCEとはモバイルアプリやSPA（Single Page Application）のように、クライアントシークレットを安全に管理できない環境での不正アクセスを防ぐためのものです。クライアントは、認可リクエストを行う際に、code_verifierというランダムな文字列を生成し、そのハッシュ値であるcode_challengeを認可サーバに送信します。クライアントがトークンを要求する際に、再度code_verifierを送信します。認可サーバは、最初のcode_challengeと、今回受け取ったcode_verifierのハッシュ値を比較し、一致した場合のみトークンを発行します。これにより、途中で認可コードを盗聴されても、code_verifierを知らなければトークンを取得できないため、不正なトークン発行を防げます。 PKCEについてはRFC7636により定義され、OAuth2.0からの変更点として挙げられており、今後も実装されるサービスが進んでいくと想定されます。
参照元：https://oauth.net/2.1/

インプリシットフローの廃止

モバイルアプリの普及に伴い、OAuth 2.0やOIDCの認証フローは進化してきました。その中でも、かつて主流だったインプリシットフロー（Implicit Flow）は、現在ではセキュリティ上のリスクからOauth2.1で廃止されます。インプリシットフローは、クライアントがアクセストークンやIDトークンを直接ブラウザ経由で受け取る認証フローです。
このフローは、クライアントシークレットを安全に管理するサーバを持たない、ブラウザのJavaScriptアプリケーション向けに考案されました。フローは以下の手順で進行します。

認可リクエスト: クライアントはresponse_type=id_token tokenを含むリクエストを認可サーバに送信します。
認証と認可: ユーザは認可サーバで認証を行い、クライアントにアクセスを許可します。
トークンの直接受け取り: 認証・認可が完了すると、認可サーバはアクセストークンとIDトークンをURLの**フラグメント（#以降の文字列）**に含めて、クライアントにリダイレクトします。
クライアントサイドでの処理: クライアントのJavaScriptがURLのフラグメントからトークンを抽出し、利用します。

このフローの利点は、認可コードをトークンに交換する中間ステップがないため、シンプルで実装が容易であることでした。
ただし、インプリシットフローの最大の弱点はセキュリティにあり、インプリシットフローは下記理由により廃止されます。

ブラウザ履歴への記録: 多くのブラウザはURLのフラグメント部分を履歴に残しませんが、中には記録されるものもあり、トークンが漏洩するリスクがあります。
リファラーヘッダーへの漏洩: 悪意のあるサイトへリダイレクトされた場合、リファラーヘッダーを通じてトークンが漏洩する可能性があります。

今後はインプリシットフローの代わりに、PKCEを使用した認可コードフローにより、更なる高セキュリティの認証フローを実現することが出来ます。
参照元：https://oauth.net/2.1/

prompt=createの追加

OIDCにおけるprompt=createは新規アカウント作成時のUXを改善するための拡張機能となります。promptパラメータはこの認証フローのUIを制御するための重要なパラメータです。prompt=createは標準的なpromptパラメータ（login、consentなど）の拡張として、ユーザに新規アカウント作成フローを強制する目的で導入されました。これは、特に新規ユーザの獲得を目指すアプリケーションにとって非常に便利な機能です。通常、ユーザがログインボタンをクリックすると、認可サーバはユーザのログイン状態を確認し、既存のアカウントがあればログイン画面をスキップして認証を完了させることがあります。しかし、prompt=createがリクエストに含まれている場合、この挙動は変わります。

新規登録画面への誘導: prompt=createは、認可サーバに対し、ユーザの既存のセッションやアカウントの状態に関わらず、最初にアカウント作成画面を表示することができます。これにより新規登録を促すことができます。

参照元：https://openid.net/specs/openid-connect-prompt-create-1_0.html#name-prompt-parameter

CIBAの標準化

CIBA（Client Initiated Backchannel Authentication）は、ユーザが操作しているデバイスとは別のデバイスで認証を完了させるための仕組みです。OpenID Foundationによって標準化された仕様で、「分離された認証（Decoupled Authentication）」フローとも呼ばれます。

これまでの認証では、サービスを利用するデバイス（例: PCのブラウザ）でIDとパスワードを入力し、同じデバイス上で認証を完結させるのが一般的でした。しかしCIBAでは、サービス利用の開始（きっかけ）と、実際の本人確認（認証）を別のデバイスで行うことができます。