RFCとなった「OAuth 2.0」――その要点は？：デジタル・アイデンティティ技術最新動向（2）（2/2 ページ）
いまWebの世界では、さまざまなWebサービスが提供するプラットフォームと、サー ドパーティが提供するアプリケーションがAPIを中心に結び付き、一種の「APIエコノミー」を形成しています。この連載では、そこで重要な役割を果たす「デジタル・アイデンティティ」について理解を深めていきます。
OAuth 2.0をセキュアに使うために知っておくべきこと
スマホアプリでのFacebook IDを用いたログインには注意！
これは何も「Facebook IDでログイン」に限った話ではありません。しかし、OAuth 2.0ベースのID連携を行う場合、利用されるOAuth ServerはほぼFacebook APIになるので、ここではFacebookの名前を直接挙げています。
OAuth 2.0とProfile APIの組み合わせによってID連携を実現する際、スマホのネイティブアプリなどのPublic Clientは、Implicit Grantフローを利用することになります。
すべてのサービスがネイティブアプリ内で完結する場合には特に問題ないのですが、実際には、アプリが独自にサーバサイドにAPIを持ち、何らかのユーザー情報を保存している場合が多いでしょう。スコア情報やゲーム内通貨の残高などをサーバサイドに保存しているスマホゲームなどがそれに相当します。
この状況で、Implicit Grantフローで得たAccess TokenをAPI側で受け取り、何の検証もなしにProfile APIから返ってきた情報を元に認証してしまうと、簡単にアカウントが乗っ取られてしまいます。
詳しくはOAuth.jpの以下の記事から続く一連の記事で述べています。
もしスマホの端末所有者自身が攻撃者となり、他のユーザーのアカウントを乗っ取ろうとしている場合、
- ネイティブアプリが受け取ったAccess Tokenは、必ずしも想定するOAuth ServerがそのOAuth Clientに直接発行したものとは限らない
- APIが受け取ったAccess Tokenは、必ずしも想定しているクライアントから来たものだとは限らない
という可能性があります。開発者としてはこれら2点に十分注意し、それらをしっかり検証する必要があります。
client_secretをネイティブアプリに安易に埋め込まない
OAuth 1.0では、クライアントの特性を考慮せず、一様に署名計算用の秘密共通鍵（OAuth 1.0の仕様ではConsumer Secretと呼ばれるもの）が発行されていました。
TwitterはOAuth 1.0を採用しているため、iPhoneの各種TwitterアプリにはそれぞれのOAuth Clientの鍵情報が埋め込まれており、これは逆コンパイルなどにより漏えいするリスクがあります。Twitterの場合であれば、xAuthやReverse Authといったホワイトリスト化されたクライアントにのみ許された認証方式が存在しますが、そういったホワイトリストに載っているOAuth Clientの秘密鍵が漏えいした場合は、そのホワイトリスト自体が意味をなさなくなってしまう可能性もあります。
同様にOAuth 2.0でも、Implicit Grant FlowをサポートしていないOAuth Serverが存在していたり、Googleのように、ネイティブアプリにclient_secretを埋め込むようドキュメントで指示している場合も見受けられます。
中には、これらはどちらも同等であり、逆コンパイルされなければ安全と考えているデベロッパーもいるようです。しかし、client_secretはOAuth 1.0では署名計算のみに利用されていたのに対し、OAuth 2.0ではHTTPで直接、OAuth Serverに送信されます。そのためOAuth 2.0では、OAuth 1.0に比べ、埋め込まれたclient_secretの漏えいははるかに容易に起こり得ると考えたほうがよいでしょう。
このあたりについてはOAuth.jpの以下の記事で述べています。
Client Credentials FlowをサポートしていないOAuth Serverなどでは、client_secretが漏えいしても、そのリスクは非常に限定されたものになります。しかし、すべてのAPIの仕様を把握できないなどの理由でclient_secretの漏えいリスクをきちんと評価できない場合は、安易にclient_secretをネイティブアプリに埋め込むべきではありません。
仕様にまとめられたセキュリティ上の留意点
上記2項目以外にも、OAuth 2.0の仕様では複数のセキュリティ上の注意点が述べられています。OAuth Serverを実装する場合には必ず、OAuth Clientを実装する場合にもなるべく、「Security Considerations」の章を読まれることをお勧めします。
OpenID Foundation Japanの翻訳版は、元になっているドラフトのバージョンが少し古いのですが、英語が苦手な場合はこちらを読んでもよいでしょう。
【関連リンク】
Security Considerations (ja)
http://openid-foundation-japan.github.com/draft-ietf-oauth-v2-draft22.ja.html#anchor40
移行期の注意点
2012年8月2日、OAuth 2.0がついにRFCとして承認されました。現在IETF内で最終的なフォーマット調整などが行われているため、まだRFCとしては公開されてはいませんが、この記事が出る頃には公開されているかもしれません。
RFC化が完了すれば、OAuth 1.0の仕様はOAuth 2.0によって置き換えられるため、既存のOAuth 1.0をサポートしていたOAuth ServerなどがOAuth 2.0へ移行するケースも増えてくると思われます。個人的には、以前、ベーシック認証を廃止した際にデベロッパーを混乱させた経歴のあるTwitterの対応には特に注目しています。
一方で、長期にわたってドラフトの状態が続いたことから、同じOAuth 2.0をサポートしているOAuth Server間でも、サポートしているドラフトのバージョンが異なるなど、相互運用性に問題が生じているのも事実です。
1つのOAuth Serverのみを扱うOAuth Clientデベロッパーならば、あまり気にする必要はないかと思います。しかし、複数のOAuth Serverと連携する場合や、自身でOAuth Serverを開発する場合などは、そのあたりの背景も踏まえた上で開発を進めなければならないでしょう。特にOAuth Serverを開発する場合は、想定されるOAuth Clientの開発者が使うであろうOAuth 2.0ライブラリがどの程度最新仕様をサポートしているのか、把握しておく必要があるかと思います。
さて、次回はOpenID Foundation Japanのもう1人のエバンジェリストであるritouより、OpenID Connectについて紹介します。OpenID Connectはまだ、実際のプロダクション環境で使われるような段階には至っていませんが、OAuth 2.0ベースでよりセキュアにID連携を行うための仕様であり、OAuth 2.0とProfile APIのみでID連携を行う場合の問題点を理解する上でも、ぜひ知っておくべき仕様です。
次回の記事も楽しみにしてください。
著者プロフィール
Nov Matake
http://matake.jp□http://matake.jp■
OpenID Foundation Japan Evangelist。個人では、OAuth.jpというサイトを通じて日本語でのOAuthに関する情報発信などを行ったり、OpenID ConnectやOAuth 2.0のRubyライブラリを開発している。
Copyright © ITmedia, Inc. All Rights Reserved.