Spring Day 2016 - Web API アクセス制御の最適解
34 likes22,935 views
マイクロサービスアーキテクチャが話題を集め、コンポーネントのWeb API化が更なる急加速を見せる昨今。 とは言え「誰でも自由に叩いて良い」Web APIなんてのは事実上無く、ほぼ全てのケースで何かしらのアクセス制御が必要になります。 - Spring Security もサポートする昔ながらの「Basic認証」。古い、ということは、悪いソリューションなのか？ - 最近のAPIのアクセス制御と言えば「OAuth 2.0」がトレンディ？ Spring Security OAuth もあるし！ - 一方でAWSは「APIキー方式」を採用。なぜAWSはOAuth2ではないのか？ - Spring Security はまだ公式にサポートしていない「OpenID Connect」とは一体…？ Webにおけるアクセス制御の歴史を振り返りつつ、様々なAPIの立ち位置と共に、その最適解を探っていきたいと思います。
![[AWS EXpert Online for JAWS-UG 18] 見せてやるよ、Step Functions の本気ってやつをな](https://cdn.slidesharecdn.com/ss_thumbnails/awsxon18howfarstepfunctionsgo-211124111849-thumbnail.jpg?width=560&fit=bounds)
![[Aurora事例祭り]Amazon Aurora を使いこなすためのベストプラクティス](https://cdn.slidesharecdn.com/ss_thumbnails/amazonauroratips-170307140000-thumbnail.jpg?width=560&fit=bounds)
More Related Content
What's hot (20)
Viewers also liked (20)
Similar to Spring Day 2016 - Web API アクセス制御の最適解 (20)
More from 都元ダイスケ Miyamoto (20)
Recently uploaded (6)
Spring Day 2016 - Web API アクセス制御の最適解
- 1. #springday ∼ Basic認証？ APIキー？ OAuth 2.0？ OpenID Connect？ ∼ Spring Security で作る Web API アクセス制御の 最適解 クラスメソッド株式会社 都元ダイスケ SPRING DAY 2016 グラントウキョウサウスタワー41F ROOM3-5 2016/11/18 (Fri)
- 2. #springday よく訓練されたアップル信者、都元です。 Webアプリ屋・AWS屋 AWS歴 5年強（2011夏頃∼） Java歴 約10年（2006頃∼） Twitter @daisuke_m その他戦場 Spring, Gradle, OAuth, OpenID Connect 自己紹介 2
- 3. #springday 【 序 章 】 概要、お詫びと訂正、 そして怒涛の結論へ 3
- 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. #springday Springの話 Webブラウザによる通信の話 ステートフルなAPIの話 HTTP（not HTTPS）通信の話 もう2016年っすよ。HTTPS使おう。 今日しない話 5
- 7. #springday 結論（！？） 7 case by case 結局APIの認証は何を使えばいいの？
- 9. #springday クライアントは全てprivate networkに居る。 つまりAPI サーバへの通信経路は全てprivate。 牧歌的な世界。敵はいない。 そもそも認証（なりすましでないことの証明）要る？ SSLも要る？ パフォーマンスを犠牲にしてまで。 まずは private network の世界 9
- 10. #springday 七人の敵どころじゃない。 アクセス制御の話を聞きに来てる時点で、 SSL/TLS必須。必須。必須。 天気予報とか郵便番号検索とか、 誰が見ても害がないような情報の read-only アクセスでない限り。 それだって最近は認証するケースが多い。 OpenWeatherMap とか。 global network に晒した途端 10
- 11. #springday WHAT YOU ARE (inherence factor) 顔貌、声、指紋、署名など、その人自身の提示。 WHAT YOU HAVE (possession factor) 身分証、携帯電話等、その人だけが持っているものの提示。 WHAT YOU KNOW (knowledge factor) パスワード、秘密の質問等、その人だけが知っていることの提示。 認証の方法 11
- 12. #springday 静的・無期限のクレデンシャル 例: パスワード 静的・有期限のクレデンシャル 例: OAuth2 アクセストークン・セッションID 動的なクレデンシャル 例: リクエスト署名 (HMAC) クレデンシャルの分類 12
- 13. #springday 【 第 1 章 】 Basic認証 13 （と、Digest認証）
- 14. #springday HTTPではパスワードが平文で流れるので論外。 ログアウトできない。 「パスワードを保存する」チェックボックス。 見た目かっこ悪い。 （ブラウザのHTTP-BASIC認証） 14
- 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. #springday HTTPSという前提条件の下、適切に運用すれば 直ちに安全に影響を及ぼすレベルではない。 ただ、敢えて勧めはしない。なぜなら… API における BASIC認証 over HTTPS 16
- 17. #springday Attack windowが大きい。 リクエスト毎に静的・無期限なクレデンシャルが 毎回流れる。 SSL/TLSとて万能ではない。 Heartbleed, POODLE, FREAK, etc. BASIC認証 over HTTPS を否定するとすれば 17
- 19. #springday 【 第 2 章 】 APIキー署名 19
- 20. #springday AWSのAPIが採用している認証方式。 HMAC（ハッシュ関数に基づくメッセージ認証符号） hash( secret + message ) の値は secretを知らなければ計算できないでしょ？ リクエスト署名用 API キー 20 注：上記の式は、イメージです。素人が素朴に作ったオレオレHMACには脆弱性が発見されており、 HMACの算出は、実際はもうちょっと複雑な式を使います。
- 21. #springday message ＝ リクエスト内容＋現在時刻 等 secret = シークレット・アクセスキー 上記でHMACを計算、これを署名とする。 リクエストと共に、ヘッダで署名を送る。 署名は動的クレデンシャル。 HMACによるリクエスト署名 21 実は、OAuth 1.0a はこんな感じの仕組みでリクエストを行う。 つまり、リクエスト毎に面倒な計算が必要。
- 22. #springday RFC的なスタンダードは存在しない。（欲しい） 署名算出にあたって、"aws4_request" という 文字列定数を利用するオレオレ感。 V1∼4までがあるが、V1は脆弱なので利用しない。 V4の利用を推奨。 AWS Signature Version 4 22
- 23. #springday 23 幕間
- 25. ここで一旦、CMです。 25
- 28. #springday prismatixは、UI は提供しません。APIだけ。 ECサイトの UI を持つフロントエンドシステムは、 prismatix API を利用する「クライアント」 「顧客」「クライアント」「prismatix」 3者のアイデンティティ(ID)を連携、コントロール するアクセス制御機構。それが OAuth 2.0 。 prismatix API 28
- 29. #springday 【 第 3 章 】 OAuth 2.0 29
- 30. #springday 認証をするための仕組みじゃねェ。 認可をするための仕組みでさえねェ。 A があらかじめもっている認可を B に対して 部分的に委譲するための仕組み。 そもそも OAuth とは 30 認証：通信相手が誰か、確認すること。 認可：リクエストが許可されるかどうかを決めること。
- 32. #springday 一般的な API アクセス制御 OAuthによるアクセス制御の特徴 32 OAuth による アクセス制御 #springday
- 34. #springday エンドユーザは神様である前提のプロトコル。 つまり、エンドユーザに対する認可の仕組みは 定義していない。（スコープ外） OAuth 2.0 におけるエンドユーザの権限管理 34
- 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. #springday 【 第 4 章 】 OpenID Connect 36
- 37. #springday むしろ OAuth 2.0 よりもシンプル。 個人的に、とっっっっても面白い技術。 でも実は Web API の認証には あんまり関係が深くない。 というわけで、今日の話のスコープ外。 OpenID Connect 37
- 38. #springday あるところに、とあるアプリがあり、それを操作しているエンドユーザがいました。 アプリはエンドユーザが誰なのか知りたくなりました。（ユーザを認証したい） が、アプリ自身ではユーザのパスワードを管理したくありません。 そこでアプリは、第三者の「既にパスワードを管理しているシステム」(OpenID Provider) に、 エンドユーザを連れて行って（リダイレクト）、代わりに認証をしてもらいました。 OpenID ProviderはID/passを確認したら、「この人は都元さんだよ」というデータに電子署 名をつけて、アプリに渡します。 アプリは、OpenID Providerの公開 を使って署名を検証します。 検証が成功するということは、この人は確かに都元さんなんだ、と確認が持てます。 もし正しいID/passを示せないのであれば、OpenID Providerはこのデータに署名するわけが ないのだから。 （OpenID Connect がしてくれること） 38
- 40. #springday 認証と認可は複雑。 本当に仕組みが必要か、考える。 BASIC認証 over HTTPS は害悪ではない。 が、お勧めもしない。 クライアントを神に位置づけるのであれば、 APIキー署名方式は適切な選択肢。 ただし、仕様がオレオレ化するので、標準化が望まれる。 まとめ 40
- 41. #springday OAuth は2つの主体間で認可を委譲する複雑なモデル。 オーバースペックの可能性があるので、要熟考。 OpenID Connect Web API 認証には縁が深くない。 でも面白いヨ。 まとめ 41