私とJohn Bradley(Ping)とNaveen Agarwal(Google)が共著者としてクレジットされている「OAuth PKCE（ピクシー）」 が、[RFC 7636] として発行されました。元々はOAuth SPOP (Symmetric Proof of Posession)と言っていたものですが、Symmetricに限らない形に拡張したため、Proof Key for Code Exchange (PKCE、ピクシー＝妖精）と名を改めて現在に至っています。 この規格はOAuth 2.0 [RFC6749]のPublic Client の Code Interception Attack 脆弱性に対応するもので、ephemeral keyを生成して、これを使ったProof of Possession of Key をします。RFC6749と後方互換性がありますし実装も簡単
Basic認証とOAuthとその辺の情報について整理しておく。OAuthや認証・認可について説明しようとすると、1文字記述するたびに誤りが含まれてしまう可能性があるので、本当に緊張感を持って記述しなければならない。それでもなお、この文章にはたくさんの誤りが含まれている。 UsernameとPasswordを受け取って認証する形式の認証方法。UsernameにはEmailを使うこともある (要は全ユーザの中で一意なことが保証されていてかつ他の人がその値を知っていても特に問題がないという情報であればOK)。Passwordは本人しか知り得ない情報。 OAuthという仕様に則って提供される認可方法。古いOAuth 1.0と、OAuth 1.0の複雑なところなどを改善したOAuth 2.0がある。一般的にはOAuth 2.0を使うことが多いが、例えば幾つかのサービスの提供している認可方法はOAut
OAuthプロバイダを提供することになったとして、アクセストークンに有効期限を設けるべきかどうかについて考えたい。OAuth 2.0の仕様にはアクセストークンの期限切れに関係する仕様が定義されているし、セキュリティをより強固にするためにアクセストークンは一定期間で期限切れにするべきだという主張があったと思う (確認していないので無いかもしれない)。しかしながら、例えばGitHub API v3ではアクセストークンに有効期限を設けていない。この投稿では、アクセストークンの有効期限に関係して起こり得る問題を取り上げる。 アクセストークンに有効期限を持たせておくとちょっと安全 アクセストークンが悪意のある第三者に漏洩してしまった場合、そのアクセストークンに認可されているあらゆる操作が実行可能になってしまうという問題がまず存在する。ここでもしアクセストークンに有効期限が存在していたとすれば、その操
追記 (5/7 20:30): 本文中に「まともなブラウザーであれば、そのフラグメントを URI の一部にするようなことはないから、オープン・リダイレクターには送られない。」とありますが、少なくとも Chrome と Firefox はリダイレクト時に URI フラグメントをそのまま保つ (i.e. 不十分な redirect_uri チェック & オープン・リダイレクター & インプリシット・フローの場合、アクセス・トークン入りの URI フラグメントを、ブラウザーがそのままリダイレクト先へのリクエストに用いる) とのことです。続報があり次第追記します。 追記2 (5/7 23:50): John Bradley 氏自身によるフォローアップを訳しました。 Covert Redirect and its real impact on OAuth and OpenID Connect を、と
こんばんは、ritouです。 Twitterの問題が発覚した際、こんなgistも書きました。 gist:5053810 · GitHub 今朝、こんなTweetしました。 https://twitter.com/ritou/status/317429458657222657:twitter:detail:left gistに書いた通り、私の考える今回の問題の本質はoauth_callbackの管理、その一言に尽きます。他に2legged OAuthが入るとごちゃごちゃするので、OAuth 1.0の実装のポイントについてまとめてみました。 なんとなくOAuth怖いって思ってるやつちょっと来い from Ryo Ito もちろんこれだけではわけがわからないと思うので、説明が聞きたければどこかで話してもいいです。ぜひ声をかけてください。 普段は秋田にいますが、唯一この勉強会にはよく参加しているの
怪しいクライアントを許可していないのに勝手に twitter で DM が送信されていた 何やら Twitter で勝手に DM が送られるという事案が発生していた模様。 調査の結果、ある web ページにアクセスしただけで、Twitter の token credentials が攻撃者に知られてしまう *1 ということがわかったらしい。 下記ページにまとめられていたのだけどパッと読んですぐには攻撃手法を理解できなかったので、いろいろ考えたことを書き残しておく。 「ちょっとこれみてくれない」とurlを送るスパムDMの解析と解説 - Togetter 簡潔な解説が以下の記事にあったので、簡潔な説明で理解できる人は下記記事参照。 gist:5053810 (DM踏んだだけでアレな件はTwitterのOAuth実装がク○だと思う) 【拡散希望】twitterの新型ウイルスがヤバい URL踏んだ
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
おひさしぶりです、@novです。 最近は、新しいFacebook iOS SDK使ってるアプリを見つけるとまずToken置換攻撃を試みていますが、結構高い確率でこの攻撃に対して脆弱なアプリがみつかります。困ったものです。。 そんななか、2週間ほど前に、Micosoft Researchの人がIETF OAuth WGのメーリングリストに同じ問題を提起していました。該当Threadでは少し話題が脱線している部分もありますが、もともと最初にこの問題を提起したJohn BradleyがOAuth 2.0 CoreにSecurity Considerationsを追加する流れのようです。 これが現状の改善につながれば良いのですが、そう簡単に行かないかもなとも思います。というのも、この問題、なかなかデベロッパーにとって理解されない傾向があります。 そこで今日は、これまでいくつかのアプリデベロッパーに
こんにちは、ritouです。 今回の内容は、Webブラウザからのみ利用できるサービスや特にiPhoneアプリのみ提供しているサービスではなく、 「一つのサービスをWebブラウザからもモバイルアプリからも利用できるようなサービス」についての話です。 こちらで取り上げられている内容です。 http://subtech.g.hatena.ne.jp/mala/20120214/1329199851 内容は OAuth 2.0でユーザーが認可をする"アプリケーション"とは何？ ユーザー、認可サーバー、クライアントの３者で認識にずれがあるのでは？ 認識の違いを解消するために認可サーバー、クライアントができることは？ という感じです。 OAuth 2.0でユーザーが認可をする"アプリケーション"とは何？ いろんな答えが返ってくると思われます。 「同意画面に書いてる内容によるんじゃないすか？」 「仕様見
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
昔から、「OpenIDは認証でOAuthは認可だ」などということが言われます。しかし、その言語の意味を取り違えている方が結構多い気がしています。「もうOpenIDなんていらね。OAuthだけでいいじゃん」というような言説がよく流れてくるのがその証拠だと思います。OAuth認証というのもその類ですね。 そこで、今日はOAuthとOpenIDの違いを考えてみたいと思います。 OpenIDは紹介状、OAuthは合鍵 まずはOpenIDの概要の復習です。「OpenIDは認証」という言葉の内容をまずは復習してみましょう。 「認証」とは大変広い言葉でいろいろな場面で使われますが、「OpenIDは認証」という使い方の時は、「OpenIDは、いま来ている人の身元を認証」（ユーザ認証）という意味です。図にすると図1のような流れになります。 この例では、有栖さんがお客としてサービス提供をしているサイトである伊
TwitterのDM（ダイレクト・メッセージ）機能はメールよりも気軽で便利な連絡手段として普及しつつあります。でも、気をつけてください。あなたが技術者のようにTwitterのことを理解していないのであれば、DMが盗み見られる可能性は、おそらくあなたが考えている以上です。 〔2011年5月追記：個々のアプリに対して付与できる権限を、より細かく制御できるようになりました（参照：Twitterブログ: ミッション: アプリ認証でのアクセス権）。さらには連携アプリの一覧画面もありますので、プライバシーに関する機能が充実しました。詳しくはサードパーティアプリケーションとの連携方法もご覧ください。〕 〔註：本稿はなるべく多くの人に読んで頂けるように、易しく書きました。このように「註」欄で詳しい説明を書いていますが、詳しく知りたい人向けですので、読み飛ばして頂いても構いません〕 「DMで大事な話をするこ
今回から始まった「ゼロから学ぶ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（後述）を兼ねるサービスとなっています。こういった背景
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
