idcon14レポート
10月5日に行われたidcon #14に行ってきました。ヒカリエのDeNA会議室、きれいですね。DeNAステッカーとベイスターズのお水いただきました。
「JSON based Web Service」
- JSON Pointer
- JSON Patch
- JSON Schema
- ドラフト04
- バリデーション、ドキュメンテーション、ハイパーリンク
- validation & documentation
- 値に制約をつけたり型を定義したり
- title, descriptionでドキュメンテーション
- propertiesの中に属性のスキーマを入れる
- typeで型、またデフォルト値など。JSON Pathを使って別のSchemaを参照
- hyperlink
- Schemaに対するrelation, endpoint, method, media typeなど
- サンプル
- まとめ
「Multiple Personae, One "Persona"」
- ぺるそな?
- Mozilla Persona
- ログインのためのより良い方法 (better way)
- より良いとは?
- たくさんのパスワードを必要としない(ID連携)
- 複数のメアドを使い分けられる
- decentralized
- real privacy: 非営利、トラッキングを行わない
- BrowserIDのかんたんな解説(beta1)
- Identity assertion
- 検証方法
- RPはIdPからIdPのpublic-keyをもらってくるだけでOK
- IdPには誰が何をアクセスしようとしているか教える必要がない
- assertionの中にあるJWSの署名を検証できる
- 使い道: メールによるワンタイム認証フローを置きかえることができる
- RPはIdPからIdPのpublic-keyをもらってくるだけでOK
- 実装しているブラウザはない
- /.well-known/browserid → 全然みつからない
- navigator.id.* → 実装を見ない
- persona.org: fallback IdP
- persona.orgが代わりに署名してくれる
- fallback browser
- persona.orgが提供するJavaScriptで機能を提供
- 両方とも使ってしまうと結局persona.orgに頼るメールフローになってしまう
- OpenID Connect OPからid_tokenを取る方がシンプル
- 残念な感じ
- 少なくともブラウザ側実装はほしい
- ネイティブ実装
- Firefox向け → 今年Q3くらい?
- B2G (Firefox OS)にも実装予定。課金とか?
- スマホでアプリ間認証とかに使えるのでは
- 事前にIdPの証明書がわかっていればオフライン検証もできる
- まとめ
- ブラウザの鍵ペアと多段階の署名がキモ
- persora.orgにfallbackしちゃうので現状は残念
- 今後に期待?
- ところでメール連携はId連携と似ている
- メールプロバイダはIdPなのか?
- ユーザーのメールアドレス所持を保証
- パスワード再発行(refresh tokenに似てる?)
- Identifier Providerかな?
- 結論
- パスワードはサービスごとに変えましょう
- パスワードは減らしましょう
- ID連携がパスワードを減らします
- Q&A
- PersonaというサイトとRPの信頼関係は、RPが一方的にpersona.orgを信頼していて逆はないということ?
- bkihara: そのとおり。ドメインに正しくアクセスできるかどうかで担保する。
- IdPには誰が何をアクセスしようとしているか教える必要がない、などがメリット?
- bkihara: そうですね。IdPとしては公開鍵を提供しているだけ。ただし、ブラウザの鍵ペアに対する署名はあまり長時間やっていると盗まれる危険がある。仕様では24時間以内ということになっている。するとログインの度に署名が走るため、統計アタックなどがないかなーと調べている
- nov: 使っている人いる?
- PersonaというサイトとRPの信頼関係は、RPが一方的にpersona.orgを信頼していて逆はないということ?
- 感想: ブラウザで鍵ペアを生成してIdPから署名をもらうというと、PKIをJWTベースで簡単にした感じなんでしょうか。勉強したいと思います。
「日本史から学ぶID」
- (19:47)
- @masanork
- 興味を持ったきっかけ: 間に合わなかった規制改革
- 戸籍が庁舎の中でしか保管できない法律になっていた → クラウドに保存したい
- 改革はなんとかできたが、データ移行が間に合わないうちに震災が起きてしまった
- 戸籍は日本でタブー視されているようで、いつからあるんだろと思って調べはじめた
- 日本書紀を見ると、紀元前からそういうものがあったようだ
- 肉を納めさせる → 取りたてるために管理
- 渡来人も登録
- 税金逃れのために戸籍を登録しない者が発生: 女性として登録、死んだのに生きていることにしたり。今も昔も不正の手口はあまり変わってないw
- 律令制度
- 7世紀くらいになると、掘ると出てくるものがある
- 戸籍を整備して税金を取る。どれくらいの田畑をたがやしているかを調べ、計帳に記述
- 8〜9世紀に一度途断えてしまう
- 人は逃げてしまう。どうやったらいいか → 土地に税金をかけるようになった
- 人は逃げるが田んぼは逃げない。人の頭数を数える必要がなくなった → 戸籍もなくなった
- 朝鮮出兵と人掃令
- 次に頭数を数える必要があったのは徴兵
- そんなに定着はしなかった
- 1635年寺請制度 → 現在の戸籍の原型
- 宗教的な理由で戸籍的なものがあるのは他の宗教も同じ
- キリスト教でも洗礼や葬式の記録によって登録する
- ここまではバックエンドのデータベースの話だった。いよいよトークンの登場
- 往来手形: 関所を通るための手形。パスポート
- 明治維新と戸籍制度
- 岩倉具視使節団と基督教解放
- 東京駅の立てかえ: 大正3年
- 明治の戸籍は血のつながりとか関係なく建物で書いていた
- → 血のつながりで戸籍を作った
- 交通が整備され、住所が変わる人の管理をちゃんとやる必要が出てきた。寄留法 → 登録してもしなくてもよくて、あまり登録されなかった
- 関東大震災 → 表札の昔及
- 配給のために作った世帯台帳
- → 信頼できる整備されると他の用途に使いたくなる
- → 選挙に使った
- → 配給が終わったら困るよね → 住民票になった
- 戸籍と世帯台帳をつなげる仕組みが作られた
- そもそもなんで戸籍と住民票が分かれているのか、という問に対する答
- 当時はコンピュータがなく紙で管理しているので、書きかえるために信頼度が下がる。人が死んだとかめったに使わないものは戸籍として分けて残った
- 当用漢字と人名用漢字
- 住民票を法務省から自治省へ(1967)
- 漢字コードと外字問題が発生(1990年代)
- パソコンとネットの普及
- クレジットカードとパスワード、昔は心配されたけど結局使ってるよね
- 米同時テロ事件 → 本人確認の強化
- 日本には本人確認の法律がない → はじまった
- 住基ネットと反対運動
- 個人情報保護の流れ
- 住基ネット自体は合法という判決が出たが、どこまで組織間で連携していいかは、このときの判決の解釈が大きな論点
- ソーシャルメディアの台頭
- まったく別の文脈で個人が自ら情報を出していく動きが活発になっている
- キリスト教弾圧のための寺請制度が行政に使われた。配給のための世帯台帳が行政の基盤になっていった。いままた、友達関係を記述していたIDが行政に活用されようとするのかな
- IDと政府
- 管理目的を持って管理しようとしてもうまくいかない
- 何かの目的で集めたものを別の目的に使うほうがうまくいくかも
- Q&A
- nat: 今日、入るのに名刺を出してくださいと言われたが、えっ、これ本人確認なの? と思った。どうでしょう
- masanork: それはsunk costであろう。なりすますために印鑑作ったり名刺作ったりはしないだろう。役所で住基カードを出すときらわれる。運転免許の方がよかったりする。tokenの強度よりもattributeを気にしている。
- nat: 名刺の裏にお金貸しますと書いてサインするのはいいと思う。文書として成立する。一方名刺はかんたんにリプレイアタックできる面もある
- masanork: 複数枚の名刺を用意させるという手がある。自分の名刺を複数枚(2枚とか5枚とか)持っていればOK。他人の名刺を作ると私文書偽造になる?
- nat: 米国では人をだます目的で作ると罪になる
- nat: 今日、入るのに名刺を出してくださいと言われたが、えっ、これ本人確認なの? と思った。どうでしょう
- 感想: 非常に面白かったです。歴史の時間に習った、でも忘れてた、というようなものが多く出てきて、勉強になりました
「OAuth Server、セキュアに実装しようず」
- (20:32)
- 司会: @nov
- パネリスト自己紹介
- confidential clientとpublic clientの割合は?
- n: FBクライアントはimplicitだと乗っとられる場合もある
- n: mixiさんimplicitサポートしてないですよね? なぜ?
- y: 社内でサポートしたいねという話は出ては消えをくり返し、3年半経過。一番大きな理由は、過去にmixiサービスで事故ったりということもあり、シビアに考えているということ。一度やらかしてしまうと本当にオワコンになってしまう。OAuthの本来の目的である認可を考えると、ユーザーが許可したとしてサービスが良い子とは限らない。良い子じゃなかったときにPF側で何もできなくなるので、client_idを外すことはできなかった。「あなたはもうダメです」という最後の砦をくずしていない
- n: 楽天さんはどうでしたっけ?
- j: してません
- n: appiaries ではサポートしてますよね
- g: サポートしてます。redirect uriを制限し、カスタムスキーマは禁止。user credentialも許していないのでいいかな、と
- n: NRIでは気にしてます?
- k: サポートしていないところの理由はかんたんで、implicit grantいらないや、というのが多い。サポートしたところはJSのゲーム、flashからAPIを叩きたいということだった。APIを使えるclientがどんなAPIを使えるかというと情報参照程度。書き込み系はガンガンポイントを増やせるなどヤバイので、codeを使ったり、サーバーからリクエストを投げるような用途に限定するなどが現実的
- y: 気にしてるのはセキュリティーだと思う。アプリは主流がJSでブラウザだったりスマホだったりする。FBもGももうimplicit grantをサポートしてブラウザ上でアプリ書いてくださいというように、バランスが変わってきていると見ている。最後の砦とか言ってると世界に取り残されそうな危機感はある。自分で自分の首をしめないように見ながら、ある日決断するのかなあ、と
- n: public clientと両方サポートしてるときは比率どれくらい
- g: 7割くらい。3割はconfidentialを選んでみただけ的な
- n: 通信解析するとsecret送っているアプリがいたりするけど、バレるとマズイよね。むしろimplicitよりマズイと思う
- n: スマホターゲットなんだけどconfidentialしかサポートしない例はあるのか
- k: 基本的にはみんなcodeでconfidential。ただしiOSのkeystoreにちゃんと保存しましょうというところまで手が回っていない。そこがアプリ開発者の人達のモラルやノウハウにまかされている。アプリでインストールベースで全部同じsecretが入っているの、漏洩したらどうします? って言っても、こうしたらみたいのを言えないのがもどかしい。client_secretをインストールベースごとにサーバーで一意に発行するようなお客様もいない。アプリを作る側からすればimplicitでいいよね、ってなってしまう
- y: アプリをクラックされてsecret抜かれちゃうって話になっているけど、通信路からもれるのとは別の話だと考えた方がいい。ストレージをクラックするのは100%ではないのでがんばりましょうという話。通信路の場合は受ける方がSSLでしか受けないとなれば、アプリでは送るしかない。
- n: ユーザーを守るのか何を守るのかという話
- y: OAuth1に戻って署名を送ってもらえばちょっとは上がる。
- j: モバイルアプリにsecretを入れるのは昔は推奨されていたがいまは逆になっている。業界も変わってきている
- n: 悪意のあるユーザーからは守れない。client credentialをサポートしていなければ、漏れても大したことないかな、と
- n: Googleは面白いことにclient credentialをスマホアプリに埋め込ませてる。client credentialフローでは取らせないようにしてるのかな、と想像するけどわからない
-
- 会場: 認可した後の悪いアプリからの防御はどのように考えているのか
- y: ひとつは通報。誰かが見つけてくれて教えてくれたら調査します。もうひとつはAPIのアクセス数の傾向をいまのところ全部見ている。本当にヤバイものにはリミットをかけている。実際にリミットがかかったものは、誰がどのアプリでいつ、を監視している。スパイクが出たり、他のものと傾向が違う場合には調査を始める、という形
- nat: 楽天さんはstateパラメータをサポートしてないのはなんで?
- j: redirect_uriのパラメータを許可しているので、そっちでやってほしい
- y: redirect_uriは登録時に決まってしまう。パラメータをつけられないとすると困りません?
- j: 完全一致でなくある程度の範囲を許しているので、その中でパラメータをつけてもらっている
- nat: stateはクロスサイトスクリプティングを防ぐためにnonceを入れるもの。どうすんの?
- j: query_stringの部分はそのまま送るようになっている
- k: 完全一致だとconversation idがreturn_toに入っているとはじかれるので、うまく使われていなかったり
- nat: 仕様を作っている人達からすると完全一致にしてstate使えということ。オープンリダイレクタを作れてしまうので。stateを送られたらそのまま返せというのは仕様上のMUSTになっている
- k: 昔、zigorouさんのプレゼンでオープンリダイレクタ作れちゃう話はありましたね
- OpenID Connect対応する? 何が面倒?
- nov: 特に結論はないんですけど、OAuth2はドラフトが長いまま31まで来ちゃったんですが、これから実装する人はこのへんの人をつかまえて聞いてください
- 感想: 各社、顧客の要求に応じてトレードオフを決めているということですね
(21:10)
この後、同じ会場でDeNAさん提供の懇親会がありました。うにもちゃんとありましたよ。
今回のidconも面白い話ばかりでした。masanork先生の戸籍制度の歴史は本当に面白かったです。Ustreamでもう一度見直してみよう。
セッションのメモ、間違って書いている点などあると思いますのでツッコミお願いします。
