JSON Web Token (JWT) - OAuth.jp
@novです。 個人的に最近OAuth 2.0よりJWT (というかJWS) を利用するシーンが多く、毎回同じ説明するのもめんどくさいのでブログにまとめるかと思い、どうせならOAuth.jpに書くかということで、こんな記事を書いております。 （そろそろJWTとJWSは、OpenID Foundation Japanの翻訳WGで翻訳するべき？） JSON Web Token (JWT) とは、JSONをトークン化する仕組み。 元々はJSONデータにSignatureをつけたりEncryptionする仕組みとして考えられたものの、Signature部分がJSON Web Signatue (JWS)、Encryption部分がJSON Web Encryption (JWE) という仕様に分割された。 それぞれ2012年10月26日現在の最新仕様はこちら。 （JWTとJWSは既にだいぶ仕様が固
JWS 実装時に作りがちな脆弱性パターン - OAuth.jp
JOSE (Javascript Object Signing and Encryption) 愛で満ち溢れる ID 厨界隈において、燦々と輝く JWS (JSON Web Signature)、美しいですよね！ JWT がジャニーズなら、JWE は EXILE、JWS は石原さとみと言ったところでしょうか？ と、冗談はさておき、JWT をお使いの皆さんは、当然署名付けてますよね？署名検証しますよね？ そんなあなたに一言いいたい！ まだ HMAC で消耗してるの？ いや、決して HMAC オワコンとかは言ってないですよ？スマホアプリでの署名検証のために、アプリに共通鍵埋め込むのはナンセンスってだけで。 ということで、今日は JWS をお使いのみなさんに、実装時に作りがちな脆弱性パターンを2つご紹介します。 今日紹介する脆弱性の2つのうち、1つめは HMAC, RSA, ECDSA のどれを
HTTPS でも Full URL が漏れる？OAuth の code も漏れるんじゃね？？ - OAuth.jp
なんですかこれは！ New attack bypasses HTTPS protection on Macs, Windows, and Linux DHCP につなぐと PAC ファイルがダウンロードされて HTTPS であろうとアクセス先の Full URL は漏れるですって？ Web Proxy Autodiscovery ですって？ チョットニホンゴデオネガイシマス ってことで、まぁこれが実際どれくらい簡単に実現できる攻撃パターンなのかは他のセキュリティ業界の方々に後で聞くとして、この記事でも触れられてる OpenID Connect とか OAuth2 への影響について、ちょっとまとめておきましょうか。 Authorization Request & Response が漏れる response_mode=form_post なんていうのも一部ありますが、基本 OAuth2 /
OAuth / Connect における CSRF Attack の新パターン - OAuth.jp
昨日こんなのが OAuth ML に流れてました。 [OAUTH-WG] Another CSRF attack 前提条件 RP (Relying Party a.k.a. OAuth Client) が2つ以上の IdP (Identity Provider a.k.a. OAuth Server) と連携している状況で、片方の IdP に悪意がある。 悪意ある IdP = AIdP (A は Attacker の略) その他の IdP = HIdP (H は Honest の略) 攻撃フロー Victim が AIdP を使って RP へのログインを試みる。 RP は Authorization Request を AIdP に送る。 AuthZ Req には Browser Session と紐付いた state パラメータをつけている。 AIdP は Victim を認証し、必要に
NIST 800-63C を翻訳しました - OAuth.jp
先日このブログでも紹介した OAuth Revocation, JWK JWK Thumbprint 仕様の翻訳版 に引き続き、OpenID Foundation Japan 翻訳・教育 WG リーダーとしての Nov です。 先日 翻訳 WG の Facebook Page でも告知したように、現在 NIST SP 800-63-3 – Digital Authentication Guideline の翻訳を開始しています。 今日はその中から、すでに翻訳が完了している NIST SP 800-63C – Federation and Assertions のご紹介です。 Level of Assurance プロフェッショナルなみなさまのことです、すでに Level of Assurance とか LoA とかいう単語を耳にしたこともおありでしょう。 NIST SP 800-63 は、
Implicit Flow では Covert Redirect で Token 漏れるね - OAuth.jp
この記事は、先ほど書いたこちらの記事の訂正版です。 記事に入る前に、まずは全シンガポールにお詫び申し上げますm m さて、Covert Redirect についての説明は…超絶取り消し線はいりまくってる前の記事を読んでください、でいいでしょうか？ で、訂正分だけ以下に。 Fragment Handling in Redirect 宮川さんが記事にしてますね。 英語だけど。 で、まぁ要するに、(Modern Browser は) 30x リダイレクト時にリダイレクト元に付いてた URL fragment をリダイレクト先にも引っ付ける、と。 fragment は server-side には送られないけど、クライアントサイドではリダイレクト先に引き継がれる、と。 試しに http://www.idcon.org/#foobar にアクセスすると、http://idcon.org/#fooba
Rails SessionにCookieStore使った時の問題点 - OAuth.jp
今日 @mad_p さんからRT来てたこのツイートに関して、ちょっと調べたのでまとめときます。 Security Issue in Ruby on Rails Could Expose Cookies http://t.co/JlsXVEn4rZ — Ruby on Rails News (@RubyonRailsNews) September 25, 2013 前提条件 Railsではデフォルトでsessionをcookieにのみ保存して、DBなりmemcacheなりのserver-side storageには何も保存しません。 これがCookieStoreとか呼ばれてるやつです。 この場合のsession cookieは、Railsのsession object (Hash object) をMarshal.dumpしてそれに署名を付けたtokenです。 rails 4では署名付ける代
Re: OAuth 2.0のclient_secretって本当に秘密鍵ですか？ - OAuth.jp
昨日こんな記事を見かけたので、記事にまとめることにします。 OAuth2.0のclient_secretって本当に秘密鍵ですか？ 元記事にあるとおり、現状Native AppでのOAuth 2.0の実装は、API提供者・利用者ともにポリシーがバラバラで、混乱の元になっていると思います。 Googleのドキュメントにも「the client_secret is obviously not treated as a secret.」とあるわけだけど、そのくせclient_secretを使ってるし、ネットで調べても少なくない数の人がアプリに埋め込んでるので、client_secretを公開したときの問題を考えてみる。 "offline" アクセスと "online" アクセス Googleは、"offline access" に対して以下のようなポリシーを持っています。 Upcoming cha
FacebookのOAuthを使うサンプルアプリ (Rails) - OAuth.jp
@nov です。 自分で作ってる fb_graph という Facebook Graph API の Ruby ライブラリを OAuth 対応したついでに、Railsでサンプルアプリを作りました。 デモサイトはこちら。 ソースコードはこちら。 ソースコード内には localhost:3000 で使える API Key&Secret も埋め込んであるので、特に Facebook にアプリ登録しなくても動きます。（localhost:3000 以外で動かす場合は自分でアプリ登録してください） いまのところRailsのバージョンは3.0.0.RCです。 app/models/facebook.rb と app/controllers/facebooks_controller.rb を見れば、Facebook 独自の JavaScript SDK と通常の OAuth2 の Web Server
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
