まえがき
みなさん、こんにちは。ヤフーの本間です。
私はヤフーに新卒として入社し現在3年目で、Yahoo! ID連携の開発・運用を担当しています。
2018年11月にタイのバンコクで開催されたIETF 103に現地参加する機会がありましたので、この記事ではIETF 103やOAuth WGにおける議論内容と議題に挙がっていたOAuth 2.0 Security Best Current Practiceの一部をピックアップして解説しようと思います。
Internet Engineering Task Force(IETF)とは
本題に入る前にIETFの説明をします。IETFとはインターネット技術の標準化を推進する任意団体で、皆さんが普段インターネットを利用する際に使っているであろうHTTPなどの仕様もこの団体で策定されています。策定された仕様はRFC(Request for Comments)という文書で公開され誰でも見ることができます。
IETFにおける標準化の議論はメーリングリストと年に3回開催されるIETF Meetingで行われます。標準化の議論はワーキンググループ(WG)の単位で行われます。IETF MeetingではIETF参加者が一同に介しWGに分かれ議論を行います。毎回1300人以上の参加者がいるようです。
IETF 103の様子
IETF Meetingはこれまで102回行われており、私が参加したのは103回目のミーティングでした。IETF 103はタイのバンコクで11/3から11/9に開催されました。バンコク中心部のホテルの2階から7階を貸し切り、各会議室でWGの議論やハッカソンなどのイベントが行われました。
会場となったホテル
会議の様子
IETF 103の参加登録者数は1436人に登り会場は非常に活気にあふれていました。参加登録者のうち484名がアメリカからの参加者で、ついで95名が中国からの参加者でした。日本からの参加者は3番目に多く71名でした。なおこれらの数値はリモートでの参加者数も含みます。
休憩時間にはコーヒーや簡単な食事が提供され、この間にも議論が行われていました。
また、IETFでは新規参加者が感じる敷居の高さが問題になるしく、私はスケジュールの兼ね合いで参加できませんでしたが、初回参加者に向けてIETFに参加するにあたり守るべき行動規範などをレクチャーしてくれるNewcomer's Overviewというイベントが開催されていました。
また、参加者証に貼る初回参加者であることを示すステッカーが配られ、ベテランがビギナーに声をかけやすいようにして、コミュニティーに溶け込みやすくする工夫も見られました。
参加者証と初回参加者を示すシール
休憩時間中に提供された食事
Web Authorization Protocol (OAuth) WG
私はOAuth WGに参加してきました。OAuth WGはOAuth 2.0とその関連仕様について議論するWGです。OAuth 2.0とは認可のための仕様です。例えばInstagramで投稿した写真をFacebookにも投稿する許可を与えるようなケースで利用されます。
OAuth 2.0の詳しい解説は下記記事を参考にしてみてください。
ヤフーではOpenID Connectに準拠したYahoo! ID連携を提供しています。OpenID ConnectはOAuth 2.0を拡張した仕様であるため、ヤフーでもOAuth 2.0を提供していることになります。
IETF 103のOAuth WGではOAuth 2.0のセキュリティーを強化するための仕様と、特定のユースケースをカバーするためOAuth 2.0のフローを拡張する仕様について議論されました。
OAuth WGは2日開催されました。まだRFC化までされていない検討中の仕様であるドラフトごとにポイントを絞って議論行われました。
OAuth 2.0のフローを拡張する仕様
OAuth 2.0の拡張する仕様としてはdraft-ietf-oauth-reciprocalなどが議論されました。この仕様はOAuth 2.0のIDプロバイダーとリソースサーバーが相互にアクセスし合うユースケースにおいて、OAuth 2.0のフローを２回繰り返すのではなく、2回目のフローを簡略化するための仕様です。
パラメータ名が他のパラメータ名と区別が分かりにくく不明確であるという指摘があるなど、まだまだ議論が必要な様子でした。ヤフーでも似たようなユースケースに出くわすことは過去経験しており、個人的には注視したいドラフトです。
セキュリティ強化のための仕様
セキュリティー強化のための仕様としてはdraft-ietf-oauth-token-bindingやdraft-ietf-oauth-mtlsなどについて議論されました。
通常のOAuth 2.0で発行するアクセストークンなどのトークン類は電車のきっぷと同じで、第三者が取得してもそのまま使えてしまうという性質があります。銀行口座の残高をサードパーティーアプリケーションから参照するような、より高いセキュリティーレベルが求められるユースケースにOAuth 2.0を適応する場合は、Tokenの漏洩のリスクが高くこの性質は課題になります。この課題を解決する手段としてこれらの仕様が議論されました。
OAuth 2.0 Security Best Current Practiceについて
OAuth 2.0 Security Best Current PracticeとはOAuth 2.0ベースのIDプロバイダーやそのクライントを実装をする際、セキュリティー上考慮すべき点を明文化したベストプラクティス集です。2018年12月現在Internet-Draftの段階でありまだRFC化されていません。
OAuth 2.0 RFC 6749でもセキュリティー上対策すべき点が記載され、
2013年に発行されたRFC 6819でもセキュリティー上の脅威とその対策がまとめられましたが、比較的最近考案されたセキュリティー強化のためのToken Bidingなどの仕組みやブラウザーのサポート状況などの周辺環境の変化を考慮し、より安全なIDプロバイダーとクライントを実装するためのベストプラクティスを改めてまとめたのがこのドラフトです。
このBCPは推奨実装、攻撃とその緩和策について解説されています。本記事では2つ取り上げて解説します。
Refresh Token Protection
OAuth 2.0ではアクセストークンとそれを更新するためのリフレッシュトークンを使い分けることがあります。アクセストークンが第三者に漏洩した場合でも被害を低減するため、アクセストークンは比較的短い有効期限を持たせます。一方リフレッシュトークンが第三者に渡ると、アクセストークンの有効期限以上にリソースサーバーにアクセスされる可能性があるためより適切に取り扱う必要があります。(リフレッシュトークンだけが漏洩しても問題ない場合もあります)そこで、本BCPではリフレッシュトークンを安全に管理するための方法がいくつか記載されています。
RFC6749で提案されている下記対策が改めて推奨されています。
- 送信時、保管時にリフレッシュトークンを機密に保つ
- IDプロバイダー、クライアント間はTLSを用いてリフレッシュトークンを送信する
- IDプロバイダーはリフレッシュトークンがクライアントにバインドされている状態を保持しチェックする
- アクセストークンリフレッシュ時に可能であればclient_idの認証を行うべき
- IDプロバイダーは第三者がトークンの有効性を保持したままリフレッシュトークンを生成、変更、またはトークンの生成方法を推測できないことを保証しなければならない
その他、アクセストークンの更新ごとに新しいリフレッシュトークンを発行することや、上述のToken BindingやMutual TLSを用いてトークンが第三者から利用できないようにすることがなど推奨されています。
Implicitフローの利用について
ImplicitフローはAuthorization responseで直接アクセストークンを受け取るためMutual TLSやToken Bidingのようなセキュリティ対策が取りづらくAuthorization Codeフローと比較してトークンが漏洩しやすいという性質があります。Implicitフローはシンプルな仕様のため実装も簡単ですが、利便性とセキュリティー面がトレードオフになり、仕様としてもユースケースが限定されています。本BCPではID Tokenやnonceを使うこととでリスクを低減する方法が提案されています。
IETF 103開催時点のバージョンのドラフトではImplicitフローを用いるクライントはToken BidingかToken Injectionが検知できる他のgrant typeを使わなければならないとされていました。
Implicitフローの利用についてのIETF 103における議論とその後のメーリングリスト
IETF 103ではImplicitフローを非推奨とすべきかについて議論行われました。
Authorization Codeフローと比べImplicitフローはその性質上トークンが漏洩しやすいため、仕様としてImplicitフローを非推奨とすべきかという点について、議論が行われ会場で非推奨とすべきと合意が確認されました。
その結果、IETF 103直後の2018/11/09に発行されたドラフトではクライアントはImplicitフローは使うべきでない(SHOUD NOT)という表現になりました。
Clients SHOULD NOT use the implicit grant and any other response type causing the authorization server to issue an access token in the authorization response.
しかしIETF終了後のメーリングリスト上の議論で一律Implicitフローを非推奨にするのではなく、発行されるアクセストークンが第三者からは利用できないようにできる場合や、Access Token Injectionが防げる場合を除いてImplicitフローを採用するべきではないとする内容に変更される見込みになりました。
まとめ
IETF 103のOAuth WGで議論のあったOAuth 2.0 Security Best Current Practiceの内容の一部とIETF 103での議論内容をご紹介しました。IETF 103終了後にメーリングリストで議論が行われIETF 103での合意を踏まえてつつも落としどころが見つかった表現に改められる見込みになったことをご紹介しました。
Security BCPはIDプロバイダーやそのクライアントを実装するうえで、セキュリティーを担保するために重要となる指針を示すものです。IDプロバイダーやクライントにとって実装コストなどから対応が難しいものもあるかもしれませんが、ユースケース次第では関連する開発者は内容を理解し、適切に自社のサービスに取り入れることが重要になってくると思われます。
ヤフーではIETF以外にもインターネット関連技術のトップカンファレンスのような国際的な場に積極的に社員を送り出す施策を推進しています。私も所属している部門の後押しがありIETF 103に参加することができ、どのようにインターネット関連技術の仕様策定が進むのか肌で感じる経験ができました。今後もOAuth WGや関連団体の動向をキャッチしつつ、その内容を発信していければと思っております。
こちらの記事のご感想を聞かせください。
- 学びがある
- わかりやすい
- 新しい視点
ご感想ありがとうございました
