You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert
おはようございます、ritouです。 今回は、一部で先週話題なりましたOAuth 2.0のImplicit Flowについてのエントリになります。 (2012/2/7 いろいろと修正しました。) 単なる OAuth 2.0 を認証に使うと、車が通れるほどのどでかいセキュリティー・ホールができる | @_Nat Zone Thread Safe: The problem with OAuth for Authentication. 今回は以下の内容について整理したいと思います。 OAuth 2.0のどの機能にセキュリティホールがあるのか 誰が攻撃者になれるのか 対策 OAuth 2.0 Implicit Flowとは OAuth 2.0ではサードパーティーアプリケーションが保護リソースへのアクセス権限を得るためのいくつかのフローが定義されています。 (仕様中ではFlowやGrant Type
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
Firefox web browser - Faster, more secure & customizable Webサイトへのログインに新しい流行を作るかもしれない興味深い技術がMozillaから発表された。Mozillaの見込みがうまくいけば、数年後にはこの方式でどのWebサイトにもログインできるようになる可能性がある。発表された技術は「BrowserID」と呼ばれている。 Webサイトにおけるログインというのは、利用するユーザにとっても、開発するエンジニアにとっても面倒なものだ。ユーザはサイトごとに異なるIDとパスワードを入力しなければならないし、開発側はログインシステムをプライバシーの保護にも考慮しながら開発する必要がある。 「BrowserID」はこの双方の問題を解決する。開発側は数行のコードをページに挟みこむだけでログイン処理が実装でき、ユーザはどのサイトでもまったく同じUI
OAuth 1.0aの実装に悩んだことのあるPHPerのみなさん、こんばんは。 2月になって、デブサミのmixiのなんちゃらやらこういう記事でみんなOAuth 2.0のことが気になってしょうがない今日この頃ですね。 OAuth 2.0でWebサービスの利用方法はどう変わるか（1/3）- ＠IT @a_kimuraさんの記事, いいですね。 しかし、今日はOAuth 1.0aの話です。 PHPのOAuth 1.0対応ライブラリ みなさんは、OAuth 1.0aを実装するとき、どのライブラリ/コードを利用していますか？ OAuth 1.0での開発を経験された方なら、おそらく誰しも署名と複雑な認証フローには苦しめられたのではないでしょうか？ この仕組みが複雑なため、OAuthクライアントを作成するためにはOAuthのライブラリが必須でした。しかし複雑なため、ライブラリにバグが存在することもしばし
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を使うと、サービスプロバイ
SaveSave OAuth Echo - Identity Verification Delegation (Draf... For Later
@自宅（個人の見解に基づいており，所属組織などとは一切関係ありませんし，事実かどうかもわかりません） この世界に希望をもつためには批判し続けることこそが必要だ - Edward W. Said (1935-2003) なにやら2010年6月頃に従来使われていたBASIC認証でのAPIコールができなくなるらしく，OAuthまたはxAuthへの対応が必要となっております．ぶっちゃけ，作っているのはbotなので，OAuthのような仰々しい実装（ぇ）は必要ないので，簡易的なxAuthを用いようと考えました．なお，OAuth対応を行うと60分に350回（将来的には1500回）のAPIコールができるようになるらしい．これはかなり自由度が増します．というわけで，今回はxAuthに対応する話を書いておきます．例によって，実装はPHPです． 参考にしたのはこちら．というか，そのまんまです．OAuth/xAu
<< Back to Twitter API Documentation oauth/access_token (for xAuth) This documents the specific use of oauth/access_token for xAuth (browserless token exchange). The goal of this endpoint is to allow OAuth applications to directly exchange Twitter usernames and passwords for OAuth access tokens and secrets. First obtaining a request token and sending the user through the authorization page is not
วันเสาร์ที่ผ่านมาทุ่มเวลาไปทั้งวันกับการค้นหาวิธี oauth แบบไม่ต้อง Redirect ไปยังหน้าเว็บ Twitter เพื่อ Allow Request สุดท้ายก็ทำได้ด้วยการไปอ่าน Source ภาษา Python, Ruby และ PHP (ที่เขียนซับซ้อนเหลือเกิน) รวมถึงทำ Packet Sniff เพื่อตรวจจับผลการทำงาน เรียกได้ว่าบ้ามาก -*- ไม่เข้าใจว่าทำไมหาวิธีแบบที่เป็น Document ยากเหลือเกิน ต้องมานั่งแกะเนี่ย!! แต่สุดท้ายก็หา Algorithm ออกมาได้ ก่อนอื่นต้องเขียน
最近twitter APIまわりで話題に出てきているようなので。 ちゃんと追いかけきれてないけど、恐らくこれのことですね。 http://tools.ietf.org/html/draft-dehora-farrell-oauth-accesstoken-creds-00 OAuth WRAPではUsername and Password Profileとして組み込まれてます。 http://d.hatena.ne.jp/lyokato/20091118/1258524429 WRAP/2.0が来るまでにOAuth1.0aで使いたい時に。 利用状況 ブラウザがない、あるいはブラウザを使うのが適切ではない状況での いわゆるデスクトップアプリのためのもの。 組み込みだったり、搭載されているブラウザが貧弱だったりとか。 ブラウザと連携させたくない、あるいは出来ないとき。 仕様 まず始めにクライア
2010年02月15日 [Ruby][Twitter] OAuthのアクセストークンを、ブラウザなしで、Twitterのユーザ名およびパスワードのみを用いて取得する(通称：xAuth)ためのRubyのコード タイトル長めですが、大事なことなので全部書きました。 コードはこちら： メインのライブラリ/タイムラインを取得するサンプル gist: 304123 - GitHub（最終更新：2010.02.15 11:26） 発言を投稿するサンプル（上記ライブラリと組み合わせてご利用下さい） gist: 306853 - GitHub（最終更新：2010.02.18 3:09） 概要 Twitterでは、OAuthという認証のシステムが利用できる。 従来は、（ユーザ認証を伴う）TwitterのAPIを利用する際、APIの呼び出しのたびにユーザ名・パスワードを送信する必要があった。一方OAuthでは
TwitterのBasic認証APIは6月で廃止される予定なのですが、OAuthという認証方法はブラウザを起動してユーザに認証して貰わなければなりません。一見flickrアプリケーションの様な認証方法を想定しますが、OAuthはflickr認証の様にサーバから貰ったトークンをブラウザから渡して認証させる様な物ではありません。 今回OAuthの問題を解決すべくOAuthを拡張した認証方式であるxAuthが取り入れられました。 詳しくはAPIドキュメントか以下のサイトが分かりやすいかと思います。 s-take Blog.: Twitterによる簡易版OAuth: "xAuth" 従来のOAuth認証ではまずアプリケーション（OAuthコンシューマ）がTwitterに接続してRequest Tokenを取得し、認証画面を開いてRequest Tokenを承認させ、承認されたRequest Tok
最近にわかにTwitter APIのxAuth認証が話題になっています。これは主にデスクトップアプリケーション向けに用意される認証方式で、簡潔に言うと「Webブラウザで認証画面を開く必要のないOAuth」といったところです。 従来のOAuth認証ではまずアプリケーション（OAuthコンシューマ）がTwitterに接続してRequest Tokenを取得し、認証画面を開いてRequest Tokenを承認させ、承認されたRequest Tokenを使ってAccess TokenとToken Secretを取得することによって各APIにアクセスできるようになります。しかしこれはアプリケーション側の実装が複雑になる上、デスクトップアプリケーションの場合はわざわざWebブラウザへ切り替えなければならず（ブラウザを内包するものもありますが）、ユーザにとっても面倒なものです。 そこで提案されたのがxA
Rails検証報告書: プログラマの思索 Railsで特徴的なのは、CookieでHTTP セッションを管理できることだろう。 ここの仕組みが非常に分かりやすい。 Railsの後から付いた機能で一番素敵だと思うのがこの機能です。 「Cookieなんて仕様上は4KBしか保存出来ないんだから寧ろ弱体化してね？」 とか認識されることが多い気がしてならない。 コレ、導入時にも度肝を抜かれて、以降常に、 「ハンパねー、マジCookieセッションハンパねー！」 と脳内のアフロの人が言ってるんですが、大した利点に感じる人は少ないのか、他の言語やWAFで全面採用している例を見たことが無い。 そもそもセッションという言葉自体が複数の処理をまとめた単位という広義の意味とWebアプリケーションで複数リクエストにまたがってサーバー側に保存されるデータという狭義の意味が混在して使われているという事情があってWeb上
「HTTPパスワード相互認証プロトコル」は、Webシステムでのフィッシング攻撃を防止するための、新しい認証プロトコルです。この認証プロトコルはPAKEと呼ばれる暗号・認証技術に新たな手法で改良を加え、ウェブの標準プロトコルであるHTTPおよびHTTPSに適用したもので、ユーザーがパスワードでサイトの真偽性を確認できる仕組みを提供することによりフィッシングを防止します。 研究の概要 お知らせ プロトコル仕様案 draft-04 を提出しました (2015/02/19) 実験用Webブラウザ を更新しました: Firefox 35.0 and draft-04 spec がベースです 2015/03/27公開 2015/03/31更新 2015/04/10更新 実験的 WEBrick サーバー を掲載しました 2015/03/27公開 2015/03/31更新 2015/04/10更新 HTT
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
