OAuth/OIDCのセキュリティ改善に役立つ「PAR」「mTLS」「DPoP」
OAuth/OIDC拡張仕様のポイントを解説すべく、最初に登壇したのは工藤氏。Authleteは2015年に設立された、OAuth/OIDCソリューション「Authlete」を展開する日本のAPIセキュリティスタートアップ。OAuth/OIDC分野に特化して事業を展開する同社は、Web記事をはじめ、自社公式のYouTubeチャンネルや書籍などで、OAuth/OIDCに関する情報を広く提供している。
OAuthはアクセストークンを用いたAPI認可フレームワークである。フローは図の通り。認可サーバーはエンドユーザーの認証などを行い、同意確認をする。その後、APIを呼び出す側（クライアント）にアクセストークンが渡り、それを使ってAPIが呼び出されたときに、APIサーバー（リソースサーバー）は、アクセスを許可するか判断する。一方のOIDCはIDトークンを用いたID連携プロトコル。フローはOAuthをベースとし、IDトークンを、アイデンティティプロバイダからRP（Relying Party）に渡し、エンドユーザーのRPへのアクセスを認可する仕組みである。
OAuthもOIDCも、昨今登場した技術ではない。「OAuthの基本的なところは2012年にProposed Standard RFC（Request for Comments）になっている。またOIDCも2014年に仕様が確定。いずれも10年前後使われ続けている技術」と工藤氏は説明する。とはいえ、当時のまま使われてきたわけではない。「拡張仕様が登場したり、当初は問題なかったが、今では使うべきではないパターンになってしまったりと、使い方もいろいろ変わってきている。そこで、これからに向けて覚えておくべき2つのポイントを紹介したい」（工藤氏）
まずはセキュリティの改善。OAuthでは認可リクエストにまつわるさまざまな課題があった。OAuthのフローの中では、クライアントが認可サーバーに対して、「こういうアクセストークンが欲しい」という認可リクエストを行う。この認可リクエストはWebブラウザを介するリダイレクトという形で、ユーザーを巻き込んでユーザー認証を行い、アクセス承認を戻すというフローになる。このリダイレクトの存在によって、いろいろな不都合が発生していた。中でも最も大きな不都合が、「認可サーバーは直接クライアントと通信していないので、クライアントを認証できないこと」と工藤氏。クライアントから認可サーバーへの認可リクエストの送受信は、Webブラウザを介する間接通信となるため、認可サーバーはクライアントの真正性を確認できないのだ。また認可リクエストの内容をWebブラウザから秘匿できないこと、大きなサイズの認可リクエストを送信できないという課題もあった。
そこで新たな仕様として策定されたのが、RFC 9126「PAR（Pushed Authorization Requests）」である。まずクライアントは認可サーバーのPARエンドポイントに、response_typeなどのパラメータを含む「認可リクエストの内容」を登録する。PARエンドポイントはそのレスポンスとして、クライアントにrequest_uriを返却する。このrequest_uriは、その後クライアントが送信する認可リクエストに含められる。PARはこのように、クライアントが認可サーバーに、認可リクエストの内容を直接通信によって登録する仕組みである。これにより、認可サーバーがクライアントを認証できるようになるだけではない。「リクエストの内容をWebブラウザから秘匿可能になる。またWebブラウザを介さないので、大きなサイズのリクエストも送信できるようになります」（工藤氏）
またOAuthではアクセストークンの扱い方にも課題があった。広く用いられているアクセストークンは持参人（Bearer）型であり、そのアクセストークンを誰が使うかは限定できない。「そのため、アクセストークンの不正利用を防ぐ術がなかった」（工藤氏）という。
この課題を解決するには、認可サーバーがアクセストークンを発行する際、そのトークンにクライアント情報を紐付け、リソースサーバーがAPIリクエストの受付時にその紐付けを検証して、送信者の正当性を確認することが有効である。その実現方法として、工藤氏が挙げたのはTLSクライアント証明書を使う方法（RFC 8705で定義。通称mTLS）と、クライアントが動的に生成した公開鍵を使う方法（同RFC 9449。通称DPoP）の2つ。DPoPは、シングルページアプリケーション（SPA）など、mTLSの適用が難しい分野をカバーできる技術である。
OAuth/OIDCの適用シーンを広げる「RAR」「CIBA」
もう一つのポイントは、さまざまなユースケースへの対応力の強化。OAuthにおけるスコープとは、「APIの認可リクエストやトークンリクエストをする際に、こういう権限のアクセストークンをください、ということを示す値のこと」と工藤氏は説明する。対象リソースの範囲や種類、リソースの参照／更新の区別、特定／期間限定の取引などが該当する。仕様上、スコープはたんなる文字列であり、構造化やパラメータ化は可能だが、表現力に限界があった。そこでRAR（RFC 9396）では「認可詳細」を定義できるようし、表現力の向上を図っている。
また対応力の強化では、最近登場した新しい仕様というわけではないが「CIBA」も見逃せないという。CIBAはユーザー認証・同意確認に、典型的にはAPI・ID情報提供側の「公式モバイルアプリ」を用いるための仕組み。一般的なOAuth/OIDCのフローでは、Webブラウザのリダイレクトを通じて認可リクエスト・レスポンスをやり取りし、ユーザー認証・同意確認を行う。CIBAを用いると、このリダイレクトがなくなり、ユーザー認証・同意確認は公式モバイルアプリが実施することになる。これにより、ショッピングセンターのPOS端末に会員証をかざすと、ユーザーの手元の銀行アプリが取引承認を求めたり、コールセンターのオペレータに購入を伝えると、ユーザーの手元の決済アプリが購入確定を求めたり、というフローが可能になる。つまりCIBAは、セキュリティを担保しつつ、適用分野を拡大できる技術なのである。
Authleteを活用したOAuth/OIDC実装パターン
OAuth/OIDCの最新動向が分かったところで、実際に実装するにはどうすればよいか。それを解説したのが、森川氏である。まず森川氏はAuthleteというソリューションについて紹介。AuthleteはOAuthやOIDCのプロトコル処理、およびトークンのライフサイクル管理機能をAPIとして提供するサービスである。「OAuth/OIDC Component as a Serviceとして定義している」と森川氏は説明する。OAuthやOIDCに関する複雑な実装や運用をAuthleteが担うことで、「お客さまは業界標準に準拠したAPI認可やID連携の機能をスピーディーに実装できるようになる」（森川氏）という。その一方で、「例えば認可サーバーやアイデンティティプロバイダのUI/UX、お客さま自身の独自ロジックなどはAuthleteに依存することなく、自分たちで作り込むことができます」と、森川氏はAuthleteの特長を説明する。
例えば「既存システムにユーザー管理の仕組みがある」「ユーザー認証は別のソリューションを使いたい」といった場合でも、Authleteはそれらを置き換えることなく、OAuth/OIDCの機能を追加するような形で使うことができるという。
AuthleteとOAuth/OIDCサーバーの連携フローは、認可リクエストから始まる。認可リクエストを受け付けた認可サーバーは、そのリクエストの内容をそのままAuthleteに送信する。Authleteはその内容に含まれるパラメータを解釈・検証し、認可サーバーに、どのような振る舞いをすべきかを返答する。その後のトークン発行処理もAuthlete側が担当。「トークンの検証や無効化、削除なども含めてAuthlete側で管理することになります」（森川氏）
続いてAuthleteを用いた、PARの実装方法を解説。認可サーバーはPARエンドポイントを介してクライアントから認可リクエストの内容を受け取り、request_uriという識別子を発行する。クライアントはそのrequest_uriを用いて、その後の認可フローを進めていくことになる。Authleteを使う場合は、下図のような流れとなる。
まず認可サーバーは、クライアントからPARエンドポイントに送られた「認可リクエストの内容」を、Authleteに転送する。Authleteはrequest_uriを含むレスポンス内容を返却し、それを受け取った認可サーバーが、クライアントにレスポンスを返却する。クライアントはWebブラウザに、request_uriを含む認可リクエストを、リダイレクトとして返却。するとWebブラウザは、その認可リクエストを、認可サーバーの認可エンドポイントに送信する。認可サーバーがその認可リクエストをAuthleteに転送すると、Authleteが「その認可リクエストに含まれるrequest_uri」と「PARの処理時に受け取った認可リクエストの内容」を保持しているので、その次に行うべき処理を認可サーバーに指示する。
「Authleteはパラメータのチェックやクライアント認証など、PARエンドポイントへのリクエストが適切かどうかを検証する」と森川氏。またリクエストのパラメータは、URLエンコードされていることが多いが、JWT（JSON Web Token）形式が使われることもある。さらに、暗号化されている可能性もある。Authleteはそのようなリクエストであっても処理できるという。
Authleteを活用したmTLS・DPoP の実装については、一番メインとなるトークンの発行と検証のフローを紹介。Authleteが担うのは、送信者限定アクセストークンの発行と検証、そして送信者情報とアクセストークンの紐付けの管理である。そのほか、Authleteを活用したRARの実装、CIBAの実装方法についても森川氏は解説。RARの実装ではPARと組み合わせた例を紹介した。
「AuthleteはOAuth/OIDC仕様に準拠しており、先進的な拡張仕様にも対応できます。コンポーネント型のソリューションなので、認可サーバーを柔軟に開発・運用可能です。当社Webサイトでは無料トライアルのアカウントを発行しています。Webサイトではチュートリアルも提供しているほか、GitHubにてSDKや参照実装も公開しています。ぜひ、興味のある方はAuthleteのアカウントを取得して試してほしいと思います」（工藤氏）
