午後から→オーバークロック

駆け出しハッカー()によるプログラミング・サービス開発備忘録。

今更OAuth1.0についてRFC読んで勉強してみた

OAuth1.0について発表する貴重な機会があったので、 RFCや色々な方のスライドなどを参考にさせていただき、まとめてみました。

補足

  • エンコードは基本パーセントエンコーディング
  • リクエストトークンとテンポラリクレデンシャルが対応している。
  • アクセストークンとトークンクレデンシャルが対応している。

その他

  • クライアントサイドがWebアプリの場合クライアントサーバ上にクライアントクレデンシャルが存在するので漏洩することはないが、モバイル・デスクトップアプリの場合はユーザの手元にクレデンシャルがあるので漏洩は避けられない。
  • callback_urlはリクエストトークン取得時に任意に指定できるので、クライアントクレデンシャルが漏洩している場合、callback_urlを攻撃者のサーバのURLに指定することで攻撃者が検証コードを取得できてしまい、危険である。

CSRF攻撃(クロスサイトリクエストフォージェリ

意図しないリクエストを発行させられることによって起こる攻撃。
インラインフレームを使うのが常套手段。

フィードバック

  • Twitterは2010年頃まではBasic認証APIを利用させていた。まじですか。
  • リクエストトークン取得プロセスは要るのか疑問だったが、実際にOAuth2.0では無くなっている。
    • ただし、リクエストトークン自体は認可要求に対して承認をしたユーザと検証コードを送ってきたユーザが同一であることを見抜くために必要である。(参考URL
    • OAuth2.0ではリクエストトークンの代わりにstateが扱われている。

感想

OAuth1.0もクライアントサイドの実装は案外怖くない!ということがわかりました。
一方でサーバサイドはセキュリティ対策とかのベストプラクティスについてRFCでは言及されてないので大変そう。

参考