特定条件下におけるOAuth 2.0の認可応答を奪取されるリスクとその対策について - r-weblife
こんにちは、ritouです。 やっと”なんちゃらAdvent Calendar”がおさまり、これからは”一年を振り返って(遠い目”みたいな記事が増えることでしょう。その間のタイミングを狙います。 何の話か mixi Platformが導入したっていうOAuth 2.0のCSRF対策拡張を使ってみた - r-weblife の最後にちょっと書いたんですけど、モバイルアプリでOAuth 2.0を使う際にやっかいな問題が残ってました。 今回は、「ネイティブアプリケーションからOAuth 2.0を使うとき、特定の条件下において、正規のClientではない悪意のある第3者に認可応答を持って行かれて、その結果Access Tokenを取得できちゃうリスクがあるよね。どうしようか。」っていう話です。 条件っていうのは、 OAuth 2.0のClientはネイティブアプリケーションであり、Client C
認可のためのプロトコルのOAuthが認証に使えることの説明
最近、「Facebookのことが分からないので教えてください」とよく頼まれます。ごめんなさい、嘘を言いました。よく、は頼まれません。よくある、とか、しばしばある、は実体以上に良く見せようとする時に使う常套句です。気をつけて使おうと思います。 それはともかくとして。 Facebookは確かに難しいです。REST API(名前がRESTですがまったくRESTfulではないWeb API)からGraph APIへの変遷、FBMLからXFBML(参照)への変遷、そしてXFBMLの存在を隠蔽するプラグインへの変遷、更に今をときめくLikeボタンからDislikeボタン()への変遷、など諸々まとめて、「Facebook vs. OpenSocial」のお題で社内勉強会をしようと思っています。 しかし内容が多すぎるので、これらの技術の中で基盤となるOAuth 2.0(まだドラフト段階です)を取り出して、
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
