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 のどれを使っても対象になるパターン、2つめは公開鍵暗号 (RSA / ECDSA) を使っている場合にのみ対象になるパターンです。

では、さっそく行ってみましょう。

来週月曜 (2015/03/02) OpenID BizDay vol.8 が開催され、ひろみちゅせんせ・まさともせんせ・Nat さんの3名を中心に、個人情報改正を控え、「炎上レスでパーソナルデータ活用ビジネスを進めるためにどこまでが許容範囲なのか、個人情報保護法改正に関して現時点で何をどこまで気にしておけば良いか」といった内容についてみんなで考える機会が設けられます。

なんと、いつもは OpenID Foundation Japan 会員限定の BizDay が、今回は 5,000 円さえ払えば非会員でも参加できるんです！！

こらぁ上司の承認とか後回しで、いますぐ申し込まないとダメですね！！！

と、前置きはこれくらいにして、個人情報保護法改正項目の中でも、今日は「第三者提供時に提供元 & 提供先双方でその記録義務が追加される」という点について、OpenID Connect や Facebook Connect などの「外部 ID 連携」時の影響範囲について、考えてみましょう。

僕の感覚だと、普通に外部 ID 連携した場合、属性も IdP から引っ張ってくるけど、引っ張ってきた属性 (氏名とかメアドとか) はユーザーが後から編集可能な状況になっていると思います。

そんな状況で、任意の時点でユーザーから「この氏名データ、どこから来たの？」って聞かれたら答えられるトレーサビリティを確保する…

一つのアカウントに複数 IdP が紐づけ可能で、任意の IdP との紐づけを任意のタイミングで解除できる、そんな状況でもトレーサビリティを確保する…

すでにそれが可能な実装にしているものだけが、SAMLer に石を投げなさい。

これ、実装どうするかって話もあるんですが、そもそもそんなケースでもトレーサビリティ必要なんでしたっけ？って疑問が湧きますよね。

今朝こちらの Tweet みて気がついたんですが、Google が OpenID 2.0 のサポートを2015年4月20日で終了するようです。

Developers beware! Google has published its timeline for deprecation of OpenID 2.0:http://t.co/84cIS0wR1D

— Gluu (@GluuFederation) January 7, 2015

本当にそんな短期間で OpenID 2.0 止めて大丈夫なのかって気がしますが、Google OpenID 2.0 Shutdown Timetable によると、4/20で全てが止まるようです。

僕が把握しているところでは、以下のサイトは現時点でまだ Google OpenID 2.0 を使っています。他にもいっぱいあるんでしょうが、僕は把握してません。他に知ってるのあれば教えてください。

• iKnow!
• ChatWork
• ATND

OpenID 2.0 停止により、上記のようなサイトでは、いままで Google Account でログインしてきたユーザー達はログインできなくなります。

これらのサイトは、4/20までに OpenID Connect (Google+ Signin) への移行が必要です。

特に新しい話題ではないですが、定期的に質問されてる気がするので記事にしときます。

OAuth 2.0 の Core には、”code” と “token” という2つの response_type が定義されています。

それぞれ “Code Grant” と “Implicit Grant” と呼ばれることもありますし、歴史的経緯により “Code Flow” と “Implicit Flow” と呼ぶこともあります。

ほとんどのケースでは、この2つの response_type のどちらかを使っているかと思いますが、実はこれ以外にも以下の response_type のパターンが存在します。 (仕様はこちら)

• none
• code token
• id_token
• id_token code
• id_token token
• id_token code token

id_token ってのが含まれてるのは、OpenID Connect で利用する response_type なので、OAuth 2.0 だけを実装する場合は無視して OK です。

でもこんなにいっぱいあると、Server 側 (OP 側) もどこまで実装したらいいかわかんないし、Client 側 (RP 側) もどれ使うのが一番いいのかわかんないですよね。特に OpenID Connect 使う場合は。

そんなこんなで、「どれ実装したらいいの？」とか、「どれ使えばいいの？」っていう質問を、Server 側の人にも Client 側の人にも、半年に一回くらいされる気がします。

この機会に、それぞれの response_type で想定される Use-Case をまとめておきましょう。

先週末、FIDO Alliance　のメンバーが来日して、FIDO Alliance Tokyo Seminar というセミナーが開催されていました。僕も今春の #idcon vol.18 で FIDO Alliance について紹介した 時にまだいろいろ不明点が多かったのもあって、このセミナーに参加してきました。

で、参加してみて分かった事。

生体認証押し

まぁ、これは FIDO Alliance のサイト見ても、元々そうっちゃそうなんですが。

FIDO は仕様的には特に生体認証センサーとか必要ないし、FIDO に準拠してない Apple TouchID みたいなセンサーモジュールと連携したソフトウェアモジュールさえ積んでればFIDO 仕様に沿った実装は可能です。

ひとことで言うと、エンドユーザーが「端末のセキュア領域に保存されている秘密鍵にアクセスして assertion に署名できる存在」であることを認証しているに過ぎないので、その秘密鍵のロック解除に指紋使ってもいいし、PIN Code 使ってもいいはずです。

が、やはり Alliance Member には生体認証ハードウェアモジュールのベンダーが多い事もあってか、発表ではヤケに生体認証を押していました。

その影響か、Twitter とか現地での Q&A でも、生体認証のセキュリティについての質問が多かったように思います。