ホワイトハッカーを夢みて、セキュリティアカデミーでお勉強中のミーアキャット。心配性でやさしい性格で、「みんな無事ミア？」「危険はないミア？」が口癖。ちょっとしたことですぐに「キャッ！」と動揺しがち。
2021年度に新卒入社。主にWebアプリケーションや認証認可、先端領域などの診断コンサルティングを担当。面白そうな技術検証とArch Linuxが好きなゲーマーで、最近ゲームとLinux系の相性も悪くなくなってきてうれしい。
平井さんこんにちは！今日のテーマは先日教わった「SSO認証」の続きミア？
平井さん
そうです！Vol.14「SSO認証は本当に安全？気を付けるべきセキュリティポイントとは？～基本＆SAML（Security Assertion Markup Language）編～」ではSSO（Single Sign-On）認証の特徴と、それを実現するための手法の一つであるSAML（Security Assertion Markup Language）について解説しましたね。今回は、OIDC（Open ID Connect）と、その基盤技術となるOAuth 2.0について解説します。
OAuth……読み方はわからないけど、なんだかスゴそうミア！
「オーオース」ですね（笑）。OAuth 2.0は、ユーザーが他のアプリケーションに対して「パスワードを共有せずにリソースへのアクセスを認可する」ためのプロトコルです。これにより、ユーザーは自身のパスワードを提供せずに安全にアプリケーションにアクセス権を付与できます。例えば、OAuth 2.0はSNSアカウントを使って他のサービスにログインする際などに利用されます。
「SNSアカウントでログインする」はやったことあるミア！あれがオーオースだったのですね！
そうなんです。OAuth 2.0の主な役割は、ユーザーのリソースへのアクセスを管理することです。ユーザーがリソースへのアクセスを認可することで、アプリケーションがユーザーの情報を取得したり、リソースの参照・変更・削除などの操作を代理したりできるようになります。
実は、OIDC（Open ID Connect）が登場する以前は、OAuth 2.0をそのまま認証代わりとして使用したり、企業が独自の拡張を行ったりしていました。ただ、OAuth 2.0はあくまで認可を目的としているため、これを認証の代わりとして使用すると脆弱性が生じる可能性があります。
こうした課題がある一方で、便利なSSOへのニーズはどんどん高まり、「OAuth 2.0を用いて安全に認証を行いたい」という声も大きくなっていきました。そこで、OpenID FoundationによってOAuth 2.0の拡張プロトコルであるOIDCが開発されたのです。
「拡張プロトコル」ということですが、どこが拡張されているミア？
OAuth 2.0では、認可手順に関する仕様しか策定されていないため、OIDCでは認証に関する仕様（IDトークンの発行方法）を拡張して策定しています。次で詳しく説明しますね。
前提として、OIDCはOAuth 2.0の拡張仕様のため、基本的なフローや登場人物はOAuth 2.0とほとんど同じです。大きな違いとしては、OIDCを利用している場合はアクセストークンと一緒にIDトークンが発行されること。また注意点として下記のように一部の“用語”が異なる点があります。OAuth 2.0とOIDCでは同じものをそれぞれ違う言葉で示している場合があります。
| 役割 | OAuth 2.0用語 | OIDC用語 |
|---|---|---|
| アプリケーションを使うユーザ | Resource Owner(RO) | End User |
| アクセストークンを発行してもらう アプリケーション |
Client | Relying Party(RP) |
| アクセストークンを発行するサーバ | Authorization Server | OpenID Provider(OP) |
| アクセストークンを使って アクセスされるサーバ |
Resource Server |
なるほど。「ジッパー」と「チャック」みたいなものミア。
そうそう、そうなんです。混乱しないよう、ここではOAuth 2.0での用語を用いて解説しますね。
ちなみに、OAuth 2.0/OIDCには、次のような複数の認可フローが存在します。
※上記のフロー以外にも、RFC（Request For Comments／インターネット技術の標準的な仕様や、共有すべき事柄を記録するための文書データベース）などで定義されているいくつかのフローがあります。
次はこれらのフローの中で、最も一般的で安全な実装とされる「認可コードフロー」について解説します。
このフローは、主にサーバーサイドアプリケーションで使用されます。クライアントがユーザーの認可を得た後に認可コードを取得し、そのコードを認可サーバーに送信してトークンを取得します。そのため、パスワードをクライアントに隠ぺいしつつ、アクセストークンの発行時にクライアントを認証できます。認可コードフローは以下の手順で行われます。
うむむ……これだけの手順があるということは、きっとセキュリティリスクも潜んでいるミア！
いいところに気付きましたね。SAMLにセキュリティリスクがあったように、OAuth 2.0/OIDCにもセキュリティリスクがあります。ここでは代表的な例である「認可コード横取り攻撃」と、その対策を紹介しますね。
認可コード横取り攻撃は、認可サーバーによって発行された正規の認可コードを、悪意のあるサードパーティーのアプリなどが横取りをし、それを利用してアクセストークンを取得することを目的とした攻撃です。スマホアプリなどで、正規のアプリが送った認可リクエストに対し、認可コード発行時のコールバックURLにカスタムURLスキームが利用されていた場合に、悪意のある別アプリへ認可コードが漏えいしてしまうなどのリスクが想定されます。
横取りなんてひどい！対策はあるミア？
OAuth 2.0の拡張仕様「PKCE（Proof Key for Code Exchange）」が有効です。PKCEでは、まずクライアントがverifierとchallengeを生成し、認可URLにリダイレクトする際に、challengeを送信します。その後、アクセストークンの発行時に、認可コードとverifierを送ることで、認可サーバーが先に送っていたchallengeとの整合性を確認。その結果、不正な値であればアクセストークンは発行されないのです。
なるほど、攻撃者の知らない合言葉を使って確認するようなイメージなのミア？
そんなところですね。Open ID Connectのリスクを最小限に抑えるためには、トークンの管理やセキュリティ対策の実装が欠かせません。クライアント側でも適切な対策を講じ、ユーザーのリソースを守ることが重要です。
正直ちょっと難しかったけれど、横取りされないように気を付けるミア。今日はいろいろ教えてくれてありがとミア！
今回紹介した脆弱性はあくまでOAuth 2.0/OIDCにおける一例です。ユービーセキュアでは、OAuth 2.0/OIDCを利用したシステムや、認証基盤にOIDCを利用しているシステムに特化した診断も行っていますから、少しでも気になることがあったら気軽に相談してみてくださいね！