Spring Day 2016 - Web API アクセス制御の最適解

Spring Day 2016 - Web API アクセス制御の最適解

1. 1. #springday ∼ Basic認証？ APIキー？ OAuth 2.0？ OpenID Connect？ ∼ Spring Security で作る Web API アクセス制御の 最適解 クラスメソッド株式会社 都元ダイスケ SPRING DAY 2016 グラントウキョウサウスタワー41F ROOM3-5 2016/11/18 (Fri)
2. 2. #springday よく訓練されたアップル信者、都元です。 Webアプリ屋・AWS屋 AWS歴 5年強（2011夏頃∼） Java歴 約10年（2006頃∼） Twitter @daisuke_m その他戦場
 Spring, Gradle, OAuth, OpenID Connect 自己紹介 2
3. 3. #springday 【 序 章 】 概要、お詫びと訂正、 そして怒涛の結論へ 3
4. 4. #springday マイクロサービスアーキテクチャが話題を集め、
 コンポーネントのWeb API化が更なる急加速を見せる昨今。 とは言え「誰でも自由に叩いて良い」Web APIなんてのは事実上無く、
 ほぼ全てのケースで何かしらのアクセス制御が必要になります。 今日する話 4 Spring Security もサポートする昔ながらの「Basic認証」。
         古い、ということは、悪いソリューションなのか？ 最近のAPIのアクセス制御と言えば「OAuth 2.0」がトレンディ？
         Spring Security OAuth もあるし！ 一方でAWSは「APIキー方式」を採用。なぜAWSはOAuth2ではないのか？ Spring Security はまだ公式にサポートしていない「OpenID Connect」とは一体…？ Webにおけるアクセス制御の歴史を振り返りつつ、様々なAPIの立ち位 置と共に、その最適解を探っていきたいと思います。
5. 5. #springday Springの話 Webブラウザによる通信の話 ステートフルなAPIの話 HTTP（not HTTPS）通信の話 もう2016年っすよ。HTTPS使おう。 今日しない話 5
6. 6. #springday スライドを書き進めても、
 Springの話やJavaのコードが
 ほとんど出てきませんでした（汗 無理やりひねり出しても仕方ないので
 気楽な感じで開き直って、
 イベント趣旨からズレた話します！ お詫び 6
7. 7. #springday 結論（！？） 7 case by case 結局APIの認証は何を使えばいいの？
8. 8. #springday 認証：通信相手が誰か、確認すること。
   （＝ なりすましでないことの証明） 認可：リクエストが許可されるかどうかを決 めること。 認証と認可は、本来、相互に独立した概念。 しかし多くの場合、認証した上で
   「その主体が権限を持つかどうか」
 という視点で認可を行う。 認証と認可 8
9. 9. #springday クライアントは全てprivate networkに居る。
 つまりAPI サーバへの通信経路は全てprivate。
 牧歌的な世界。敵はいない。 そもそも認証（なりすましでないことの証明）要る？ SSLも要る？ パフォーマンスを犠牲にしてまで。 まずは private network の世界 9
10. 10. #springday 七人の敵どころじゃない。 アクセス制御の話を聞きに来てる時点で、
 SSL/TLS必須。必須。必須。 天気予報とか郵便番号検索とか、
 誰が見ても害がないような情報の
 read-only アクセスでない限り。 それだって最近は認証するケースが多い。
 OpenWeatherMap とか。 global network に晒した途端 10
11. 11. #springday WHAT YOU ARE (inherence factor) 顔貌、声、指紋、署名など、その人自身の提示。 WHAT YOU HAVE (possession factor) 身分証、携帯電話等、その人だけが持っているものの提示。 WHAT YOU KNOW (knowledge factor) パスワード、秘密の質問等、その人だけが知っていることの提示。 認証の方法 11
12. 12. #springday 静的・無期限のクレデンシャル
   例: パスワード 静的・有期限のクレデンシャル
   例: OAuth2 アクセストークン・セッションID 動的なクレデンシャル
   例: リクエスト署名 (HMAC) クレデンシャルの分類 12
13. 13. #springday 【 第 1 章 】 Basic認証 13 （と、Digest認証）
14. 14. #springday HTTPではパスワードが平文で流れるので論外。 ログアウトできない。 「パスワードを保存する」チェックボックス。 見た目かっこ悪い。 （ブラウザのHTTP-BASIC認証） 14
15. 15. #springday 散々disられているが、決定的な否定理由が見つからない。 BASIC認証 over HTTPS は、OAuth 2.0（後述）及び その周辺プロトコルにおける、1つの技術要素。 Access Token Request, Revocation, Introspection API における BASIC認証 over HTTPS 15 Is HTTPS and Basic Authentication secure enough for banking webservices (RESTful)? http://security.stackexchange.com/questions/44811/
16. 16. #springday HTTPSという前提条件の下、適切に運用すれば
 直ちに安全に影響を及ぼすレベルではない。 ただ、敢えて勧めはしない。なぜなら… API における BASIC認証 over HTTPS 16
17. 17. #springday Attack windowが大きい。 リクエスト毎に静的・無期限なクレデンシャルが
 毎回流れる。 SSL/TLSとて万能ではない。 Heartbleed, POODLE, FREAK, etc. BASIC認証 over HTTPS を否定するとすれば 17
18. 18. #springday 静的なクレデンシャルが毎回流れるのが問題ならば、
 nonceを利用したチャレンジ&レスポンスで、
 動的なクレデンシャルにしてしまえば良いのでは？ チャレンジ＆レスポンスなので、
 HTTPリクエストが必ず2往復する。 結論：Web APIには向かない。 Digest認証 18
19. 19. #springday 【 第 2 章 】 APIキー署名 19
20. 20. #springday AWSのAPIが採用している認証方式。 HMAC（ハッシュ関数に基づくメッセージ認証符号） hash( secret + message ) の値は
 secretを知らなければ計算できないでしょ？ リクエスト署名用 API キー 20 注：上記の式は、イメージです。素人が素朴に作ったオレオレHMACには脆弱性が発見されており、
   HMACの算出は、実際はもうちょっと複雑な式を使います。
21. 21. #springday message ＝ リクエスト内容＋現在時刻 等 secret = シークレット・アクセスキー 上記でHMACを計算、これを署名とする。 リクエストと共に、ヘッダで署名を送る。 署名は動的クレデンシャル。 HMACによるリクエスト署名 21 実は、OAuth 1.0a はこんな感じの仕組みでリクエストを行う。 つまり、リクエスト毎に面倒な計算が必要。
22. 22. #springday RFC的なスタンダードは存在しない。（欲しい） 署名算出にあたって、"aws4_request" という
 文字列定数を利用するオレオレ感。 V1∼4までがあるが、V1は脆弱なので利用しない。 V4の利用を推奨。 AWS Signature Version 4 22
23. 23. #springday 23 幕間
24. 24. #springday 最近、都元がやってるお仕事です。 要するに、ECサイト等を作るためのAPIサービス 商品やカテゴリのマスメンや検索 顧客管理 注文や決済の処理 prismatix 24
25. 25. ここで一旦、CMです。 25
26. 26. #springday prismatix の開発を取り巻く環境 26
27. 27. #springday 都元、前職は某スタートアップ。 現職、クラスメソッド （ブログの会社?） スタートアップとしての prismatix 27
28. 28. #springday prismatixは、UI は提供しません。APIだけ。 ECサイトの UI を持つフロントエンドシステムは、 prismatix API を利用する「クライアント」 「顧客」「クライアント」「prismatix」 3者のアイデンティティ(ID)を連携、コントロール するアクセス制御機構。それが OAuth 2.0 。 prismatix API 28
29. 29. #springday 【 第 3 章 】 OAuth 2.0 29
30. 30. #springday 認証をするための仕組みじゃねェ。 認可をするための仕組みでさえねェ。 A があらかじめもっている認可を B に対して
 部分的に委譲するための仕組み。 そもそも OAuth とは 30 認証：通信相手が誰か、確認すること。 認可：リクエストが許可されるかどうかを決めること。
31. 31. #springday 3者（本当は4者だけけど）間のやり取りで、
 エンドユーザの権限を、クライアントに委譲する手続き。 複雑。超複雑。 クライアントは、ユーザから委譲を受けた証として、
 「ユーザのIDとpass」ではなく「アクセストークン」を 入手する。 アクセストークンは、静的だが有期限のクレデンシャル。 OAuth の概要 31
32. 32. #springday 一般的な
 API アクセス制御 OAuthによるアクセス制御の特徴 32 OAuth による
 アクセス制御 #springday
33. 33. #springday 通常は、クライアントが全権を握る。 クライアントに認証を受けたユーザが、
 クライアントの監督の下に、
 クライアントの権限を以って、APIアクセス。 OAuthは、エンドユーザが全権掌握。 神様であるエンドユーザ様の許しを得たクライアントが、
 エンドユーザ様の名の下に、
 委譲を受けた権限を行使することによる、APIアクセス。 強いのは、クライアントか、エンドユーザか。 33
34. 34. #springday エンドユーザは神様である前提のプロトコル。 つまり、エンドユーザに対する認可の仕組みは
 定義していない。（スコープ外） OAuth 2.0 におけるエンドユーザの権限管理 34
35. 35. #springday 認証
 Authentication userAuthentication; エンドユーザが持つ権限（認可） 
 Collection<GrantedAuthority> userAuthorities
 = userAuthentication.getGrantedAuthorities(); OAuth2における認証（直接的にはクライアントの認証）
 OAuth2Authentication oauth2AuthN; // (has-a userAuthentication) OAuth2においてエンドユーザから委譲を受けた権限の範囲
 Set<String> scopes
 = oauth2AuthN.getOAuth2Request().getScope(); Client Credentials 認証においてクライアントが持つ権限（認可）
 Collection<GrantedAuthority> clientAuthorities
 = oauth2AuthN.getOAuth2Request().getAuthorities(); Spring security のモデル 35
36. 36. #springday 【 第 4 章 】 OpenID Connect 36
37. 37. #springday むしろ OAuth 2.0 よりもシンプル。 個人的に、とっっっっても面白い技術。 でも実は Web API の認証には
 あんまり関係が深くない。 というわけで、今日の話のスコープ外。 OpenID Connect 37
38. 38. #springday あるところに、とあるアプリがあり、それを操作しているエンドユーザがいました。 アプリはエンドユーザが誰なのか知りたくなりました。（ユーザを認証したい） が、アプリ自身ではユーザのパスワードを管理したくありません。 そこでアプリは、第三者の「既にパスワードを管理しているシステム」(OpenID Provider) に、 エンドユーザを連れて行って（リダイレクト）、代わりに認証をしてもらいました。 OpenID ProviderはID/passを確認したら、「この人は都元さんだよ」というデータに電子署 名をつけて、アプリに渡します。 アプリは、OpenID Providerの公開 を使って署名を検証します。 検証が成功するということは、この人は確かに都元さんなんだ、と確認が持てます。 もし正しいID/passを示せないのであれば、OpenID Providerはこのデータに署名するわけが ないのだから。 （OpenID Connect がしてくれること） 38
39. 39. #springday まとめ 39
40. 40. #springday 認証と認可は複雑。 本当に仕組みが必要か、考える。 BASIC認証 over HTTPS は害悪ではない。 が、お勧めもしない。 クライアントを神に位置づけるのであれば、
 APIキー署名方式は適切な選択肢。 ただし、仕様がオレオレ化するので、標準化が望まれる。 まとめ 40
41. 41. #springday OAuth は2つの主体間で認可を委譲する複雑なモデル。 オーバースペックの可能性があるので、要熟考。 OpenID Connect Web API 認証には縁が深くない。 でも面白いヨ。 まとめ 41
42. 42. #springday 42 絶賛エンジニア募集中