OAuth 2.0でユーザーが認可をする"アプリケーション"とはサービス全体のことではない - r-weblife
こんにちは、ritouです。 今回の内容は、Webブラウザからのみ利用できるサービスや特にiPhoneアプリのみ提供しているサービスではなく、 「一つのサービスをWebブラウザからもモバイルアプリからも利用できるようなサービス」についての話です。 こちらで取り上げられている内容です。 http://subtech.g.hatena.ne.jp/mala/20120214/1329199851 内容は OAuth 2.0でユーザーが認可をする"アプリケーション"とは何？ ユーザー、認可サーバー、クライアントの３者で認識にずれがあるのでは？ 認識の違いを解消するために認可サーバー、クライアントができることは？ という感じです。 OAuth 2.0でユーザーが認可をする"アプリケーション"とは何？ いろんな答えが返ってくると思われます。 「同意画面に書いてる内容によるんじゃないすか？」 「仕様見
単なる OAuth 2.0 を認証に使うと、車が通れるほどのどでかいセキュリティー・ホールができる
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
TwitterのOAuth仕様変更、DMアクセスには再度ユーザーの”許可”が必要 - うさぎ文学日記
5月19日Twitterの公式BlogでTwitterのサードパーティなどのアプリケーションが使う、OAuthで設定しているアクセス権限に仕様変更があると、アナウンスがありました。 Twitter Blog: Mission: Permission これまでの”Readのみ”、”Read/Write”以外に、”Read, Write & Direct Messages”という種類が追加されることに。これを選択するとダイレクトメッセージの「読み込み」、「削除」ができなくなるようです。（送信はできるみたいですね） ユーザーにとっては、サードパーティのアプリケーションにダイレクトメッセージを読ませない、という選択肢を取ることができて嬉しいですね。 詳しい仕様は以下にあります。 The Application Permission Model | dev.twitter.com この仕様変更の適用
非技術者のためのOAuth認証(?)とOpenIDの違い入門【2023年版】
昔から、「OpenIDは認証でOAuthは認可だ」などということが言われます。しかし、その言語の意味を取り違えている方が結構多い気がしています。「もうOpenIDなんていらね。OAuthだけでいいじゃん」というような言説がよく流れてくるのがその証拠だと思います。OAuth認証というのもその類ですね。 そこで、今日はOAuthとOpenIDの違いを考えてみたいと思います。 OpenIDは紹介状、OAuthは合鍵 まずはOpenIDの概要の復習です。「OpenIDは認証」という言葉の内容をまずは復習してみましょう。 「認証」とは大変広い言葉でいろいろな場面で使われますが、「OpenIDは認証」という使い方の時は、「OpenIDは、いま来ている人の身元を認証」（ユーザ認証）という意味です。図にすると図1のような流れになります。 この例では、有栖さんがお客としてサービス提供をしているサイトである伊
bit.ly の OAuth 2.0 とか色々試してみたら色々アレだった : にぽたん研究所
ある日、うちのサービスで bit.ly 使って URL を短縮したいねーなんて話があがって、まぁ、単純に短縮化するなら、@shiba_yu36 さん作の WebService::Bitly なんか使えば簡単に色々出来て便利だなーって思いました。 で、きっと、このモジュールを使っているであろうはてなダイアリーとか見てみたら、bit.ly の設定画面があるんですね。 自分自身の bit.ly アカウントを使えば bit.ly でトラッキングとか出来るし便利だなーと思いました。 …でもね、うちのサービスの利用者の方々は、はてな民のようなリテラシーの高いユーザばかりではないのですよ。 「bit.ly の API キー」とか言っても「は？？？？？」って感じの方が大多数。 意味わからないものを設定画面につけるとなっちゃん宛にクレームがいっぱい来てしまいます。 とりあえず、bitly API Docum
OAuth 2.0になると2-legged OAuthはどうなってしまうのか - r-weblife
こんばんは、ritouです。 今回は、OpenSocial等で利用されている2-legged OAuthがOAuth 2.0時代になるとどうなってしまうのかをちょっと考えました。 けっこう使われている2-legged OAuth 説明は省略します。 2-legged OAuthによるAPIアクセス << mixi Developer Center (ミクシィ デベロッパーセンター) 下記のような特徴があります。 Consumer Key をリクエストに含み、Signatureによりそのリクエストを検証可能 Timestamp,nonceもついてる で、これがOAuth 2.0時代になるとどうなるかを考えます。 OAuth 2.0だとどうなるのか OAuth 2.0の仕様とは、簡単に言うと"なんとかしてAccess Tokenを取得"して、あとはそれを使って"なんとかしてリソースアクセスする
OAuth2 gemを使ってmixi Graph APIにアクセス - OAuth.jp
OAuth2 gemのインストール 現状OAuth2 gemはOAuth 2.0の古いspec (draft 0?) に準拠しているので、mixiがサポートしているdraft 10に対応したOAuth2 gemをここからgit clone & rake installする。 https://github.com/nov/oauth2 あとはこんな感じ。 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 require 'rubygems'require 'active_support/all'require 'oauth2' config = { :mo
進捗は95%？OAuth 2.0 Draft 13の内容をざっくりまとめる - r-weblife
OAuth 2.0のDraft 13出ました。 draft-ietf-oauth-v2-13 - The OAuth 2.0 Authorization Framework Facebookやmixi Graph APIなどを使って開発されたことがある方は、OAuth 2.0 Draft 10の仕様はほぼ理解されていると思います。 Draft 10は単体である程度まとまった仕様として書かれていましたが、そのあとのDraft 11から構成の見直しなどが行われました。 もうそろそろ決まりそうだという噂があるので、今一度ざっくり最初からまとめ直していきます。 ただ、ClientやAuthorization Serverなど、基本的な説明は省略しています。 Draft 11以降に出てきた(と思われる)説明などを簡単にまとめたつもりです。 毎度のことながら、長いうえにこれは翻訳ではないので、厳密に調
OpenID Connect Core draft 01の内容をななめ読み - r-weblife
[Openid-specs-ab] Connect-core and Connect-AB OpenID Connect/AB周りの仕様について、さっぱりMLに貢献できておりませんが、少しでも近況を多くの人に広めて良いものができる手伝いができればと思っています。 今回は、"OpenID Connect Core 1.0 draft 01"です。 名前の通り、Coreということで用語やフロー、やりとりされる内容が定義されています。 Terminology OAuth 2.0の用語に加えて、OpenID関連の以下の用語が加えられています。 OpenID Provider (OP) : OpenID ConnectのメッセージをサポートするAuthZ Server Relying Party (RP) : Client と Resource Servers(?) OP Endpoints : A
OAuth 2.0でWebサービスの利用方法はどう変わるか（1/3）- ＠IT
OAuth 2.0で Webサービスの利用方法はどう変わるか ソーシャルAPI活用に必須の“OAuth”の基礎知識 株式会社ビーコンIT 木村篤彦 2011/2/2 TwitterがOAuth 1.0を採用したのを皮切りに、今では多くのサービスがOAuth 1.0に対応しています。国内でも、例えば、マイクロブログ型コラボツール「youRoom」、小規模グループ向けグループウェア「サイボウズLive」、「はてな」のいくつかのサービス、「Yahoo!オークション」、リアルタイムドローツール「Cacoo」などがOAuth 1.0に対応したAPIを公開しています。 ここ数年でOAuthはさまざまなWebサービスのリソースを利用する際の認証方式として普及してきました。これは大きなプレーヤーがサポートしたことも一因ですが、OAuthの持つ以下の2つの特徴によって、「OAuthを使うと、サービスプロバイ
情報セキュリティ技術動向調査（2010 年上期）：IPA 独立行政法人 情報処理推進機構
本報告では 2010 年上半期のアイデンティティ管理技術に関する動向として、User Managed Access [1] の動きを概観する。 2.1 背景 分散環境におけるアクセス管理は、古くて新しい課題である。組織や企業の内部、あるいは信頼関係のある組織間では、ポリシーに基づいてどのようなアクセスを許可するかを判断するサービスをPDP（Policy Decision Point：ポリシー決定点）、PDPの判断に基づいて実際にアクセス制御を実行するサービスをPEP（Policy Enforcement Point：ポリシー実行点）とし、アクセス管理の大元を PDP に集約することが一般的であった。しかしインターネット・サービス同士の Web API による疎結合な連携に対しては、このような旧来の中央集権的なモデルをそのまま当てはめることが難しい場合も少なくない。 Web API によるイ
Twitterさん、OAuthのアクセス権限の細分化を！ : akiyan.com
Twitterさん、OAuthのアクセス権限の細分化を！ 2010-09-07 TwitterのOAuth認証を利用するサービスを作ってみたが... 一昨日の日曜日(9/5)に、クックパッドさんのオフィス提供による 『TFJ CodeCamp #2』 という1日開発合宿に行きまして、TwitterのOAuth認証を使ったサービスを初めて作ったんです。ユーザーのタイムラインを読んでいろいろやってくれるタイプのサービスを。で、実際OAuth認証するサービスを公開することを考えてみたんですが、どーにも無視できないリスクがありまして。 まず、TwitterのOAuth認証のアクセス権限レベルって、「全部のデータが読める」or「何でもできる」しかありません。今回のサービスはタイムラインさえ読めればいいのですが、OAuth認証としては全部のデータを読める要求しかできなくて、その認証をしてもらったならば
OAuthプロトコルの中身をざっくり解説してみるよ - ( ꒪⌓꒪) ゆるよろ日記
「おーおーっすっ!」 てなこって、TwitterのAPIのBASIC認証も6月末に終了してOAuth/xAuthに移行するというこの時期に、あらためてOAuthについて勉強してみたんですのよ? OAuth認証を利用するライブラリは各言語で出そろってきてるのでそれを使えばいんじゃまいか? というと話が終わるので、じゃあそのライブラリの中身はなにやってんのよってことを、OAuthするScalaのライブラリ作りながら調べたことをまとめてみました。 間違っているところもあると思うのでツッコミ歓迎です＞＜ OAuthってそもそもなんなの? ものすごくざっくりというと「API利用側が、ユーザ認証をAPI提供サービス側にやってもらうための仕様」って感じでしょうか? BASIC認証の場合、API利用側が認証に必要なアカウントやパスワードを預かる必要があるわけです。悪意のあるAPI利用側が「なんとかメーカー
“OAuth”は何と読むか
“OAuth” は何と読むのか、が話題になることがある。 たしか最初は “oath” と同じ発音だった（これが「オース」）けど 今は “Oh Auth” と発音をするのだと書かれていたのを見た気がするので “oauth pronounce” で検索してみたらまさにそれが出てきた。 "OAuth" is pronounced "Oh Auth" and has two syllables "OAuth" is pronounced "Oh Auth" and has two syllables "OAuth" の発音は "Oh Auth" で、2音節だよ。 経緯についてはこう。 OAuth was originally called "OpenAuth" but then AOL took the name, so we renamed to "OAuth". We originally p
Twitter APIのBASIC認証は2010年6月に「廃止予定」（→8月まで延長）（→廃止された模様）
Twitter APIのBASIC認証は2010年6月に「廃止予定」（→8月まで延長）（→廃止された模様） 2010年01月05日 11:51Twitter 昨年12月にパリで開催されたインターネットのイベント LeWeb’09 で Twitter のプラットフォームディレクターの Ryan Sarver さんが登壇して いくつかの発表を行ったらしいんだけど その中にこういうのがあった。 Twitter Spawned 50,000 Apps To Date, Will Open Up Firehose For More starting Basic Auth decprecation in June 2010. 2010年6月から Twitter API の BASIC 認証が deprecated になるとのこと。 Deprecated というのは「非推奨」「廃止予定」という意味で こ
OAuthのセッション固定攻撃について（翻訳） - ものがたり(旧)
Explaining the OAuth Session Fixation Attackという文章が興味深いものだったので翻訳してみた。何か解決策を思いついた人はOAuthのメーリングリストに送ってあげると良いと思う。って僕は参加してもいないのだけど。あと誤訳とかはコメントしてもらえれば対応します。ワタクシ実のところOAuthなんて使ったこともなかったりして。 （原文はリンク先にもある通り、Eran Hammer-Lahav氏からcc-by 3.0 usで提供されている。） 追記: 日本でもニュースになっていた: http://www.atmarkit.co.jp/news/200904/23/oauth.html 追記2: 元記事の画像がアップデートされていたので、追従して更新 以下翻訳: 先週、われわれが発見して対応したOAuthのプロトコルセキュリティ問題には語るべきことが多くある。
OAuth Sequence Diagram Template - 日向夏特殊応援部隊
OAuth Sequence Diagram Template とりあえず、OAuth のお勉強用にテンプレ化。Web Sequence Diagrams すげー便利だなー。 participant User participant Consumer participant "Service Provider" note over Consumer 6.1 Obtaining an Unauthorized Request Token end note Consumer->"Service Provider": "6.1.1. Consumer Obtains a Request Token" activate "Service Provider" "Service Provider"->Consumer: "6.1.2. Service Provider Issues an Unauth
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
https://hueniverse.com/2012/07/oauth-2-0-and-the-road-to-hell/
http://www.hueniverse.com/hueniverse/2009/04/explaining-the-oauth-session-fixation-attack.html
http://www.hueniverse.com/hueniverse/2009/03/sunday-morning-homework.html