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は、セキュリティを担保しつつ、適用分野を拡大できる技術なのである。
