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のアカウントを取得して試してほしいと思います」（工藤氏）
