OAuth.jp

Amazon が、Login with Amazon というAPIおよびそれに付随する JS / iOS / Android SDKs を出してきました。

以下の記事にあるように、OAuth 2.0 ベースで認証連携を行う仕組みです。

Amazonアカウントでアプリやサイトにログイン、「Login with Amazon」を提供開始：ITpro

しかし、この Login with Amazon、まさに僕が以前以下の記事で紹介した「Facebook ID でログイン」の間違った実装方法を、公式ドキュメントで推奨してしまっています。

デジタル・アイデンティティ技術最新動向（2）：RFCとなった「OAuth 2.0」――その要点は？ (2/2) - ＠IT

この Amazon のドキュメントを読んで (or 「Facebook ID でログイン」を実装した経験を元に) Login with Amazon を自身の Web Site や iOS / Android アプリに導入すると、まず確実にあなたのサイト / アプリのアカウントがハイジャックされるような脆弱性を生むことになります。

@IT の記事からのリンクは OAuth.jp の Posterous -> Tumblr 移行に伴いリンク切れになってしまっているので、ここにも OAuth 2.0 Implicit Flow を認証連携に使うことの危険性を説明するエントリーをリンクしておきます。

“なんちゃら iOS SDK” でありそうな被害例

Facebook の場合は、上の記事にあるような response_type=code+token を iOS / Android アプリでは使えないので、以下の記事末尾にあるような対処法も用意されています。

「OAuth 2.0 (Implicit Flow) でログイン」の被害例

が、ざっと Login with Amazon のドキュメントを読んだ限り、そのような対処法が一切用意されていない。

これはもう、Login with Amazon を導入した時点で、Amazon 側の対応無しではあなたのサイト / サービスの脆弱性を止めることができないということです。

既に一部有識者より Amazon 側に連絡が行っているようなので、さすがにこのまま Amazon が何の対応も取らないということは考えにくいですが、Amazon が何らかのアップデートを出してくるまで、Login with Amazon を使ってはいけません。

ご注意を。

[追記 2013.06.04]

Login with Amazon の問題点、解決されました。詳しくは以下の記事を。

Login with Amazon、もう使っても大丈夫！

ずいぶん前に「OAuth 2.0 Core & Bearer Spec 翻訳公開！」で紹介したように、OAuth 2.0 Core & Bearerは、OpenID Foundation Japanの翻訳WGで翻訳を公開していましたが、2012年に両specがRFC化されたのを受け、今回RFC版も翻訳しました。

• The OAuth 2.0 Authorization Framework (RFC 6749)
• The OAuth 2.0 Authorization Framework: Bearer Token Usage (RFC 6750)

前回翻訳したdraft版から仕様自体に大きな変更はありませんが、特に

• まだdraft版も読んだことが無い人
• 自社のAPIドキュメントからdraft版の翻訳にリンクしている人

などは、RFC版を参照していただければと思います。

いまこれらとは別に、”OAuth 2.0 Threat Model and Security Considerations (RFC 6819)” という、OAuth 2.0の利用に際して注意すべきセキュリティ上の特徴・注意点などについてまとめたドキュメントを翻訳中です。こちらも翻訳完了次第公開予定。(追記: 2013.01.25 翻訳公開済)

最後に、2/1に東京ミッドタウンのYahoo! Japanオフィスで #idcon 15th ~ YConnect & Future of Authentication ~ というイベントをやります。OAuth 2.0ベースのOpenID次世代仕様であるOpenID Connectについて、世界で初めてOpenID Connect対応API (YConnect) を一般公開したYahoo! Japanの担当者の方の話も聞けるので、興味あったら参加してください :)

2011年12月のOpenID Summit Tokyoで、2012年中のOpenID Connect対応を宣言したYahoo! Japanが、本日ついに宣言通りOpenID Connectをサポート開始しました。

もともとOAuth 2.0も対応していなかった（よね？）ので、OAuth 2.0対応も同時リリースです。

まだバグとかあるっぽいけど、何はともあれ世界の大手IdPの中で一番最初にproduction環境でOpenID Connect対応できたのはすばらしい！

まだOpenID ConnectのDiscoveryとDynamic Registrationには対応していないので、Nov RPに “yahoo.co.jp” とか入力しても使えない状態ですが、それは今後に期待です。

YConnectをちょこっと触ってみて思った要望とかは以下のgistにまとめていってます。

scopeにopenidが指定されてるのにtoken responseにid_tokenが含まれてないとか、response_type=code+id_tokenの時にcodeとid_tokenがredirect_uriのfragmentではなくqueryについているなどの問題は、ただのバグとして修正すれば良いでしょう。

それ以外でいま気になってる点としては、以下の2点です。

• response_type=code+tokenサポートしてもらわないとserver-side componentを持つmobile appから使おうとしたときにいろいろめんどくさいことになっちゃうのはFBとか見てたら明らですが、現状のYConnectは「サーバーサイド」アプリとして登録した場合response_typeにcodeかcode+id_tokenしか指定できないみたいです。これはちょっとやめた方が良い気がします。
• あと、id_tokenのsignature algorithmはdefault RS256ということで進んでいるので、YConnectだけがHS256だとまたYAuthとか言われちゃったりしそうですね。

それ以外にも、なぜかyahoo.co.jp以外のドメインのメアドはverfiedじゃなくても返してくれる (試しに hoge@hoge.com というメアドを登録してみたらそれ返してきたw）のにyahoo.co.jpのメアドは返してくれないというのも不思議といえば不思議ですが、まぁ社内調整とかいろいろめんどくさいことありそうですし、それが原因でOpenID Connect対応のスケジュールが遅れるくらいならとりあえずそれでもいいのかなとも思います。

Implicitの方でscopeにopenidが指定された時にnonceが必須になってるかとかもチェックしたかったのですが、なんかいま「クライアントサイド」のアプリを登録しようとするとエラーになっちゃうバグがあるようなので、そちらはまた明日にでも。覚えてれば。

OAuth 2.0 draft 0の時点で対応してきたFacebookのように、これからOpenID Connectのbreaking changesに追随するのは大変だと思いますが、引き続きがんばってください！あと、OpenID Connectにbreaking changeがある時に一番大きな声で文句言える立場にいるので、ぜひOpenID Connect Interopにも積極的に参加していただければ :)

@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は既にだいぶ仕様が固まってきているものの、まだIETFのInternet-Draftなので注意）

• JSON Web Token (JWT, draft 04)
• JSON Web Signature (JWS, draft 06)
• JSON Web Encryption (JWE, draft 06)

JWEはまだ実際に使うケースが無いので、ここでは説明しない。

追記:
draft versionが違いますが、JWT仕様翻訳版とJWS仕様翻訳版もご参考に。

Signed JWT

JWS使ってSignatureつけられたJWT。

HeaderとPayloadとSignatureという3つのセグメントから構成される。

Headerは署名アルゴリズムなどを含むJSONを、URL-safe Base64 Encodingした文字列。

Payloadは実際に送信したいJSONデータそのものを、URL-safe Base64 Encodingした文字列。

Signatureは、HeaderとPayloadを “.” で連結した文字列に対して、Headerに指定されたアルゴリズムで署名をして、その署名をURL-safe Base64 Encodingした文字列。

サンプルはJWT Spec Section 3.1 (draft 04の場合) を読むこと。

追記:
draft versionが違いますが、JWT仕様の翻訳版の該当箇所はこちら。

Signature Algorithms

サポートされているアルゴリズムは、これまた別仕様のJSON Web Algorithm (JWA) で規定されている。

• JSON Web Algorithm (JWA, draft 06)

JWA Section 3 (draft 06 現在) では、JWSの署名アルゴリズムとして以下のアルゴリズムがサポートされている。

• HMAC-SHA256
• HMAC-SHA384
• HMAC-SHA512
• RSA-SHA256
• RSA-SHA384
• RSA-SHA512
• ECDSA-SHA256
• ECDSA-SHA384
• ECDSA-SHA512

正直ECDSA (楕円曲線暗号) ってのは僕もよく理解していなし、Ruby以外で使いたい場合にどう書けばいいかとかさっぱりなので、個人的には共通鍵使う場合はHMAC、公開鍵使う場合はRSAを使っている。

例えば、こんな感じ。

1. 認証サーバーからiOSアプリに渡すデータには (認証サーバーの秘密鍵を使って) RSA-SHA256使って署名
2. iOSアプリからリソースサーバー (認証サーバーとは別) に渡すJSONには、Step 1で認証サーバーに署名されたJWSに入ってる共通鍵を利用してHMAC-SHA256使って署名
3. リソースサーバーはiOSアプリからStep 1で発行されたJWSとStep 2で発行されたJWSを同時に受け取って、Step 1のJWSを検証した後そこに含まれてる共通鍵でStep 2のJWSを検証
4. リソースサーバーはレスポンスに (リソースサーバーの秘密鍵を使って) RSA-SHA256使って署名

（iOSではSHA256よりSHA1の方が使いやすいらしく、HMAC-SHA1とRSA-SHA1使ってたりすることもあるが..）

各言語のライブラリ (情報求む！)

• Ruby json-jwt
• Python pyjwkest
• Java Nimbus JOSE+JWT
• PHP PHP Akita JOSE, JOSE
• Perl JSON::WebToken

Rubyのjson-jwtとPHPのJOSE (2番目の方) は僕が作ってるので、README (希望としてはSpecも) とか読んでも使い方分からない場合は僕に直接聞いていただければと思います。

それ以外はあんまり詳しく使い方知らないので、使い方についてはドキュメント (あれば) 読むなりそれぞれの作者に直接聞いてください。それぞれの作者に紹介するくらいならできます。

node.jsとかObjective-CにもJSON Web Tokenのライブラリは見かけるのですが、HMACしかサポートしてなかったりしていまいち使えそうなの見つけられてません。（多分Google Wallet APIでHMACなJWSが使われてるので、それだけサポートしたライブラリがあるんだと予想）

ここにない言語でRSAもサポートしてるライブラリご存知でしたらお教えいただけるとうれしいです。

今朝fb_graphにこんな要望が来てて知ったのですが、Facebookが新たなAccess Token Introspection APIを出したようです。

Adding support for /debug_token endpoint · Issue #269 · nov/fb_graph

こんなリクエストを送ると

https://gist.github.com/3896829

こんなレスポンスが帰ってくる、と。

https://gist.github.com/3896826

“data” ってなんやろとかApp Token無いと使えへんのメンドイなとか思ったりはしますが、ちゃんと別のClientに発行されたAccess Tokenをinput_tokenとして送るとエラーが帰ってくるし、Success Responseにはscopeとかissued_atとかも付いてくるので、いろいろと使い勝手は良さそうですね。まぁ例のごとく完全に独自仕様ですが。

って実際にGraph API Explorerで試したら、issued_at返ってこないですが（謎

オフィシャルドキュメントはこちら。

Debugging Access Tokens and Handling Errors