認可と認証技術についてのスライドを書きました - ngzmのブログ
認可と認証技術 OAuth 1.0、OAuth 2.0 および OpenID Connect に関するスライドをアップしました。 アプリ開発で知っておきたい認証技術 - OAuth 1.0 + OAuth 2.0 + OpenID Connect - from Naoki Nagazumi www.slideshare.net 開発している Web アプリで、OAuth 1.0 や OAuth 2.0 および OpenID Connect の認可と認証技術を組み込んだ時に、あれこれ調査して知り得た技術をまとめたものです。 130ページくらいの力作です！ぜひご覧ください。 デモ これのデモはこちらにあります AuthsDemo デモのソースコードはこちらです。 GitHub - ngzm/auths-demo: This is a demo program with using OAuth
OAuth 2.0 Threat Model and Security Considerations
Abstract 本ドキュメントでは, OAuth 2.0仕様が定めるSecurity Considerationsの範囲を超え, OAuth 2.0プロトコルに関する包括的脅威モデルを基に, さらなるセキュリティ上の検討項目を示す. Status of This Memo This document is not an Internet Standards Track specification; it is published for informational purposes. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review
RFCになったOAuth 2.0を使ってGoogleはどれだけパスワード入力を減らせるのか - r-weblife
※ 2012/10/17 少し文章を修正しています。 こんばんは、ritouです。 OAuth 2.0(とBearer Tokenの使い方)がRFCになりました。 RFC 6749 - The OAuth 2.0 Authorization Framework RFC 6750 - The OAuth 2.0 Authorization Framework: Bearer Token Usage 最新仕様に合わせてAPIを提供しているサービスはついに「OAuth 2.0の最新仕様(Draft 31)」じゃなくて「RFCで定義されているOAuth 2.0の仕様」とか言えるわけですね。 せっかくなので何か書こうと思ったところで9月末ぐらいに流れていたGoogleの話を思い出しました。 先月出されてたブログエントリ : Google Developers Blog: Adding OAuth 2
RFCとなった「OAuth 2.0」――その要点は？
RFCとなった「OAuth 2.0」――その要点は？：デジタル・アイデンティティ技術最新動向（2）（1/2 ページ） いまWebの世界では、さまざまなWebサービスが提供するプラットフォームと、サー ドパーティが提供するアプリケーションがAPIを中心に結び付き、一種の「APIエコノミー」を形成しています。この連載では、そこで重要な役割を果たす「デジタル・アイデンティティ」について理解を深めていきます。 再び、デジタル・アイデンティティの世界へようこそ 前回「『OAuth』の基本動作を知る」ではOAuthの仕様がどういうものかについて説明しました。今回は引き続き、 OAuth 1.0とOAuth 2.0の違い OAuth 2.0をセキュアに使うために知っておくべきこと について述べていきます。 OAuth 1.0とOAuth 2.0の違い クライアントタイプの定義 OAuth 2.0では、O
第1回 OAuthとは？―OAuthの概念とOAuthでできること | gihyo.jp
今回から始まった「ゼロから学ぶOAuth」。全4回の特集にて、これからのWebサービスを開発する上で不可欠な技術「OAuth」について取り上げます。初回は、OAuthの概念について取り上げます。 はじめに はじめまして、iKnow!改めsmart.fmの真武です。現在smart.fmでは、OAuthやOpenID、OpenSocial、Semantic WebやActivity Streamなどといった新しい技術の導入を積極的に行いサイトを活性化させるとともに、smart.fm APIを通じて我々の技術を外部のデベロッパの方々にも提供しています。 smart.fmは日本最大のOpenID Relying Partyであるだけでなく、国内では数少ないOAuth Consumer（後述）およびOAuth Service Provider（後述）を兼ねるサービスとなっています。こういった背景
bit.ly の OAuth 2.0 とか色々試してみたら色々アレだった : にぽたん研究所
ある日、うちのサービスで bit.ly 使って URL を短縮したいねーなんて話があがって、まぁ、単純に短縮化するなら、@shiba_yu36 さん作の WebService::Bitly なんか使えば簡単に色々出来て便利だなーって思いました。 で、きっと、このモジュールを使っているであろうはてなダイアリーとか見てみたら、bit.ly の設定画面があるんですね。 自分自身の bit.ly アカウントを使えば bit.ly でトラッキングとか出来るし便利だなーと思いました。 …でもね、うちのサービスの利用者の方々は、はてな民のようなリテラシーの高いユーザばかりではないのですよ。 「bit.ly の API キー」とか言っても「は？？？？？」って感じの方が大多数。 意味わからないものを設定画面につけるとなっちゃん宛にクレームがいっぱい来てしまいます。 とりあえず、bitly API Docum
PerlでOAuth 2.0を使ってみた - hide-k.net#blog
携帯の緊急地震速報の音が怖いので、「会いたかった」に変えるHackを募集しています。 こんばんは。 OAuth 2.0は仕組も特徴も理解していたのですが、実際に実装の必要が出てきたので今更ながら初めて使ってみました。 仕様は現在draft15というステータスで公開されています。(The OAuth 2.0 Authorization Protocol) OAuth 2.0の特徴としてはHTTPSを使って通信経路を暗号化することによりトークンを直接やりとりすることが可能となっています。そのため署名が必要なくなり、あの悪夢のような署名検証をしなくて済むようになったのが大きなメリットです。 とはいえ、読んでもよくわかんないのでコードにしてみます。Authorization ServerとResource Serverとして使ってみるのはFacebook。クライアントサイドフローとサーバーサイドフ
Big Sky :: TwitterのBasic認証廃止は約半分のデスクトップクライアントを殺した。
さて、TwitterがBasic認証を廃止して1ヶ月が経とうとしています。 皆さんクライアントをOAuth対応したり、乗り換えたりしたでしょうか？ 今までBasic認証で動いていた、ちょっとした捨てコード、どうなってるでしょうか？ Twitterが始まった当初、gtktwitterというデスクトップGUIで動くTwitterクライアントを作りました。まぁ作りはそれ程優れた物じゃなくて、RTなんか無い頃でfriends_timelineが見れて、発言出来て、@によるリプライが出来る程度の物でした。 ただ純粋なC言語だけでGTKおよびcurlを使ったクライアントという事もあり、一部のgeekからは人気があったみたいです。 さてこのgtktwitterを今回、Basic認証が消え去った現状でも動くようにしてあげようと思い、今回改造を始めた訳です。 まず大きな壁にぶち当たりました。 Twitter
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - sorah/nginx_omniauth_adapter: Use omniauth for nginx auth_request