2014/02/13 デブサミ2014【13-C-5】これからのネイティブアプリにおけるOpenID Connectの活用 #devsumiC
-
- いいね！1
osamu
@osamunmun
ID Tokenで登場するnonceは、OAuth2.0のAuthorization Code Flowのstateと同じような役割と理解しておけばいいのかな #devsumiC
2014-02-13 15:32:16
Kaoru Maeda 前田 薫
@mad_p
ネイティブアプリに鍵を埋め込む? -- OAuth 1.0では署名が必要なため、アプリに署名鍵(シークレット)を入れる必要があった -- アプリをのぞき見て鍵を盗むということがおこった #devsumiC
2014-02-13 15:33:24
Kaoru Maeda 前田 薫
@mad_p
id_tokenの署名 -- HMAC_SHA256 - 共通鍵暗号方式 共通鍵はアプリに埋め込むべきではない -- サーバーサイドで署名検証する場合、サーバーを守れるので問題なかった #devsumiC
2014-02-13 15:35:45
Kaoru Maeda 前田 薫
@mad_p
HMAC_RS256 - 公開鍵暗号方式による署名 -- 共通鍵をアプリに埋め込む必要がなくなった #devsumiC
2014-02-13 15:36:57
Kaoru Maeda 前田 薫
@mad_p
トークン置き換え攻撃補足 -- 自社アプリ以外用に発行されたトークンが送りつけられることを想定して防御する必要がある #devsumiC
2014-02-13 15:40:51
Kaoru Maeda 前田 薫
@mad_p
調べてみたところ、サーバーにFB IDを送るとそのままログインできてしまう例もあった。10個くらいのうち、ちゃんと動いているのはfood spottingだけ。他のは全部ダメだった #devsumiC
2014-02-13 15:41:41
Shinichi Tomita
@stomita
#devsumiC （Implicit Profileをクライアントアプリのためのもの、って定義だと、エンプラFW内アプリがカワイソス）
2014-02-13 15:41:48
Kaoru Maeda 前田 薫
@mad_p
今度はユーザーではなくデバイスを認証する話 -- ゲームなどは特にユーザー認証しないものもある。だいたいデバイスIDをサーバーに送っているだろう #devsumiC
2014-02-13 15:43:00
Kaoru Maeda 前田 薫
@mad_p
デバイスIDの種類 -- 今はなきUDID; UUID(乱数), Vendor Id, Ad Id, Device Token (push) -- Android ID #devsumiC
2014-02-13 15:43:31
Kaoru Maeda 前田 薫
@mad_p
みんなデバイスIDを送って認証したつもりになっている -- よほどしっかり設計しないと脆弱性になってしまう -- リクエストをキャプチャしておき、後でリプレイすると別人としてログインできてしまうなど #devsumiC
2014-02-13 15:44:17
Kaoru Maeda 前田 薫
@mad_p
Device IDはBearer Tokenである -- ベアラートークン。お金みたいなもの。出したらすぐに使える(無記名) -- cf: 飛行機の搭乗券: パスポートと照合してからでないと使えない(記名式) #devsumiC
2014-02-13 15:45:26
Kaoru Maeda 前田 薫
@mad_p
Bearer Token -- 持っていることが利用するための唯一の条件 -- 漏れたらオワリ。一方、使いやすい #devsumiC
2014-02-13 15:46:15
Kaoru Maeda 前田 薫
@mad_p
OAuth 1.0 vs OAuth 2.0 -- 1.0: リクエストに署名をつけていたので改竄は検知できた -- 2.0: SSL前提にしたので署名が不要、便利になったが、トークン置き換え攻撃が可能に #devsumiC
2014-02-13 15:47:14
Kaoru Maeda 前田 薫
@mad_p
OAuth 1.0: 共通鍵だったので、アプリから漏れるよね - 公開鍵で署名がつけられると便利だが、OAuth1.0でも2.0でも考えられていなかった → OpenID Connectの出番 #devsumiC
2014-02-13 15:48:13