開始
大西氏：
本日はモデレーターを務めさせていただく大西と申します。よろしくお願いいたします。
現在、株式会社InnoScouterにてCTOを務めており、B2B向けのSaaSを開発しています。
それでは、本日の登壇者を紹介させていただきます。技術同人作家のAuth屋さん、よろしくお願いします。
Auth屋氏：
Auth屋と申します。OAuthとOpenID Connectに関する技術同人誌を執筆しており、技術書典や技術同人誌博覧会での出展も行っています。今回の発表では、その著書から特に重要と感じるエッセンスを抜粋してお話しします。どうぞよろしくお願いいたします。
大西氏：
よろしくお願いします。皆様、素晴らしいリアクションをいただき、本当にありがとうございます。Auth屋さんの人気や評価が、このリアクションからも伺えますね。
それでは、早速ですが、LTの発表に移りたいと思います。よろしくお願いいたします。
Auth屋氏：
今回は『仕様が読めるようになるOAuth2.0、OpenID Connect入門』というテーマで発表いたします。
まずは、本日の発表内容の目次をご紹介します。
※実際にデモ画面で操作しながら解説しているので、ぜひ動画をご覧ください！
Q&A（抜粋）
質問「認可コードやアクセストークン、シークレットキーなど、色々な言葉が出てきてますが、この辺の言葉の定義は決まっているのでしょうか。HPなどによっては、どの言葉をどの言葉をどの役割として使っているのか分からなくなる時があります」Auth屋氏の回答：
OAuthにおけるこれらの言葉は、RFC6749というドキュメントで明確に定義されています。私が使用している用語も、この文書での定義に基づいています。
IDaaSサービスの例として、Firebase AuthenticationやAuth0などがありますが、それらの文書ではIDトークンを異なる目的で使用する場面もあるように読み取れることがあり、確かに混乱の元となることがあります。
しかしながら、IDトークンに関しても、OpenID Connectの文書上でその用途や定義はしっかりとされています。
質問「人間が介在しない認証フローシステム間の連携やバッチからのアクセス等ではClient Crdentialフローが使われると思っていますが、非推奨だとすると推奨されるのはどのような方式でしょうか。」Auth屋氏：
非推奨と書いたのはインプリシットフローのことで、Client Crdentialフローのことではありません。元々モバイルなどのパブリッククライアント用のフローとして、インプリシットフローというものがあったのですが、アクセストークンの差し替えのようなことが、簡単に行われてしまうので、非推奨になってます。
代わりに推奨されているのは、今日紹介した認可コードフローに対して、PKCE（ピクシー）という追加仕様を用いる方法です。
大西氏：
今日の話の中で、クライアントにも2種類あるということだったと思います。そのうち、パブリックじゃない方の秘密の情報も扱えるようなサーバーで作ってるアプリケーションの場合だったら、差し替えが起こりにくくなると思うのですが、その場合は、非推奨であるインプリシットフローも使っても良いものでしょうか。
Auth屋氏：
いいえ。今日紹介した認可コードフローは、そもそもコンフィデンシャルクライアントといってサーバーサイトのアプリに最適化されたアプリなので、こちらを使っていただければ、非推奨のインプリシットフローを使う意味はありません。
また、今ではパブリッククライアントでもPKCEを使った上で、認可コードフローを使うことが推奨されています。ただし、トークンリクエスト時にシークレットを含める必要はありません。パブリッククライアントでの利用時には、情報漏洩のリスクがあるため、シークレットを含めないようにしてください。
大西氏：
理解しました。
どちらのクライアントであっても、認可コードフローの方が推奨されるってことなんですね。
Auth屋氏：
そうですね。PKCEはもともとパブリッククライアント向けでしたが、現在はサーバーサイドもPKCEの利用が推奨されています。
質問「OIDCを利用すれば、セッション管理が不要でしょうか」Auth屋氏：
OIDC はアプリ側で行っていたパスワード認証と並ぶような立ち位置であり、ログイン状態になった後のセッション管理の部分を置き換えるようなものではありません。
質問「Auth屋さんの本がそれぞれどういった違いがあるのか教えてほしいです。」Auth屋氏：
まず、同人誌が3冊あります。本日の内容のほとんどは『エンジニアがOAuth2.0を整理して、手を動かしながら学べる本』から引用しています。この本は、OAuthについて基本的な内容から説明しています。
『OAuth、Oauth認証、OpenIDConnectの違いを整理して、理解できる本』はOpenID Connectの本です。OAuth認証と呼ばれる、プロフィールAPIを使った認証は何がダメかといった点を深掘りして説明することで、OpenID Connectの利点を明確にしています。
『OAuth・OIDCへの攻撃と対策を整理して理解できる本』は、OAuth・OIDCへの攻撃と対策に特化した本になります。どういう攻撃があり得て、それに対してどういう対策があるか、今日の説明では話していないステートガバナンスやpkceの話をしているのが3冊目になります。
1冊目と2冊目の青い本と緑の本を読んでいただければ、OAuthとOpenIDConnectについては理解できると思います。さらに攻撃と対策についてより詳しく知りたいという人は3冊目の本を読んでみてください。
商業誌も2冊、Amazonやその他の書店で出版中です。
https://www.amazon.co.jp/dp/B07XT8H2YG
https://www.amazon.co.jp/dp/B0BJCJJW8W
質問「認可コードフローで、いきなりアクセストークンで認可コードを発行した上でアクセストークンを発行するのは、なぜでしょうか？」Auth屋氏：
今回の解説には含みませんでしたが、実は、インプリシットフローというフローが存在します。これは直接アクセストークンを発行するフローです。いきなりアクセストークンを発行すると、認可サーバーからリダイレクトしてアプリに戻す時に、アクセストークンが入ることになります。アクセストークンがユーザーのブラウザを経由するため、このトークンの取得や書き換えが容易になります。そのため、推奨されていません。
一方、認可コードフローでは、認可コードは一度しか使用できず、それ自体の有効期限が非常に短いため、よりセキュアです。仕様では認可コードの有効期限を10分以内と推奨しています。
質問「OpenID Connectの場合でも、アクセストークンを差しられてしまう可能性はないのでしょうか？」Auth屋氏：
そのリスクは確かに存在します。しかし、at_hashを利用すれば、不正なアクセストークンの使用を検知することが可能です。IDトークン内にはアクセストークンのハッシュ情報（at_hash）が含まれているため、これを使用して実際に利用されているアクセストークンとの整合性を確認することが重要です。
質問「IDトークンの署名の検証は必要なのでしょうか」Auth屋氏：
認可コードフローにおいては、認可サーバーとサーバーサイトが直接通信するため、検証は不要と仕様に記載されています。
大西氏：
それでは、どのような状況で検証が必要とされるのでしょうか？
Auth屋氏：
それは、パブリッククライアント側でIDトークンを受け取る場合です。大西氏：
理解しました。今回のような場面では特に必要ではありませんが、パブリッククライアントでトークンを受け取る際は、検証することが推奨されるというわけですね。
