昔から、「OpenIDは認証でOAuthは認可だ」などということが言われます。しかし、その言語の意味を取り違えている方が結構多い気がしています。「もうOpenIDなんていらね。OAuthだけでいいじゃん」というような言説がよく流れてくるのがその証拠だと思います。OAuth認証というのもその類ですね。 そこで、今日はOAuthとOpenIDの違いを考えてみたいと思います。 OpenIDは紹介状、OAuthは合鍵 まずはOpenIDの概要の復習です。「OpenIDは認証」という言葉の内容をまずは復習してみましょう。 「認証」とは大変広い言葉でいろいろな場面で使われますが、「OpenIDは認証」という使い方の時は、「OpenIDは、いま来ている人の身元を認証」（ユーザ認証）という意味です。図にすると図1のような流れになります。 この例では、有栖さんがお客としてサービス提供をしているサイトである伊
In some of the feedback I have gotten on the openID Connect spec, the statement is made that Connect is too complicated. That OAuth 2.0 is all you need to do authentication. Many point to Identity Pro… 英語読みたくないという人のために簡単に解説すると… OAuth 2.0 の implicit flow を使って「認証」をしようとすると、とっても大きな穴が開きます。 カット＆ペーストアタックが可能だからです。 OAuth 認証？は、図１のような流れになります。 図１ OAuth 認証？の流れ 一見、問題なさそうに見えます。しかし、それはすべてのサイトが「良いサイト」ならばです。 Site_A
ある日、うちのサービスで bit.ly 使って URL を短縮したいねーなんて話があがって、まぁ、単純に短縮化するなら、@shiba_yu36 さん作の WebService::Bitly なんか使えば簡単に色々出来て便利だなーって思いました。 で、きっと、このモジュールを使っているであろうはてなダイアリーとか見てみたら、bit.ly の設定画面があるんですね。 自分自身の bit.ly アカウントを使えば bit.ly でトラッキングとか出来るし便利だなーと思いました。 …でもね、うちのサービスの利用者の方々は、はてな民のようなリテラシーの高いユーザばかりではないのですよ。 「bit.ly の API キー」とか言っても「は？？？？？」って感じの方が大多数。 意味わからないものを設定画面につけるとなっちゃん宛にクレームがいっぱい来てしまいます。 とりあえず、bitly API Docum
おひさしぶりです、@novです。 最近は、新しいFacebook iOS SDK使ってるアプリを見つけるとまずToken置換攻撃を試みていますが、結構高い確率でこの攻撃に対して脆弱なアプリがみつかります。困ったものです。。 そんななか、2週間ほど前に、Micosoft Researchの人がIETF OAuth WGのメーリングリストに同じ問題を提起していました。該当Threadでは少し話題が脱線している部分もありますが、もともと最初にこの問題を提起したJohn BradleyがOAuth 2.0 CoreにSecurity Considerationsを追加する流れのようです。 これが現状の改善につながれば良いのですが、そう簡単に行かないかもなとも思います。というのも、この問題、なかなかデベロッパーにとって理解されない傾向があります。 そこで今日は、これまでいくつかのアプリデベロッパーに
いままで Mix-up Attack は Client が AS 毎に redirect_uri を使い分けていれば防げると信じられてきましたが、それじゃ防げないケースもあるよってのが OAuth ML に投稿されました。 細かい解説は英語読んでもらうとして、シーケンスにするとこういうことです。 Attacker AS が (Display Name やロゴ等を通じて) 一見 Honest Client に見えるような Client (Attacker Client) を Honest AS に登録しておく必要があります。 User が Attacker AS 選んでるのに Honest AS に飛んで Approve してしまってる部分も、Attacker Proxy が利用可能な状況 (e.g., Client が HTTP なエンドポイントで Honest AS のログインボタン等を
commの発表当日「commとLINEが要求するアクセス許可の比較表を作ってみた」という記事にて、Android版commのアクセス許可を紹介しました。 そして昨日深夜、commの公式Twitterアカウントが「現時点で利用していない項目も含めてアクセス許可を求めていた」と述べ、アクセス許可の一部が削除されたようです。素早い対応ですね（後述のTweet参照）。 しかし、「不必要だった」として削除されたアクセス許可は既に表示されなくなっており、何が削除されたのか分かりません。 ちょっと気になったので、手元に保存していたアクセス許可一覧と、現在のアクセス許可一覧を比較し、削除されたアクセス許可の一覧を作成してみました。今後commがどんな機能を追加しようと思っているのかが見えてくるかもしれませんね。 目次 1. 備考：Androidのセキュリティ2. アクセス許可の削除に言及したTweet3.
Google Playのコメントで「commのアクセス許可が多い」と指摘されていたので、本当かどうか、試しにAndroid版commとAndroid版LINEの間でアクセス許可がどれくらい違うのかを見比べてみました。 追記：インストール方法はこちらです 追記：「commに「知り合いにバレずに登録する方法」が用意されていない件について」 かなり違う部分が多いだけでなく、表示順が違っていたり、「すべて表示」の部分を開く必要があったりと比較しにくかったので、比較しやすいようにメモしておきます。 説明文は、Google Playから引用したもので、あまり必要がなさそうな説明は省いています。他の説明文を読みたい場合はGoogle Playでチェックしてください。 追記（2012-10-25）：commのアクセス許可の一部が削除されました。削除された項目については「commが削除した「サービスに利用し
実行環境： ruby 1.9.3 Rails 3.1.3 ログイン認証を実現する際、認証が必要なコントローラー内に before_filter を書いてコントローラーを実行する前にログイン状態をチェックします。 たいてい、認証が必要なコントローラーが複数あります。それぞれに before_filter とそのメソッドを書くのはダサいので、before_filter を書いたコントローラークラスを作って継承させるのですが、認証させるコントローラーの数が多いと面倒になってきます。 すると「ええぃ、全てのコントローラーの親である ApplicationController に書いてしまえ！」と思うわけですが、逆に認証させたくないコントローラーが１つ２つあると、どうしてやろうか？と悩むことになります。 実現方法は色々あると思いますが、例としていくつかパターンを上げてみたいと思います。 ここでは例と
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く