OAuth vs microservices

Transcript

1. Copyright © OPTiM Corp. All Right Reserved. OAuth vs microservices 2019/10/24 (Thu.) OPTiM Technight
2. Copyright © OPTiM Corp. All Right Reserved. 2 o Kikuchi o Senior engineer, works in OPTiM Inc. o Optimal Biz (2014 ~) o OPTiM Store (2016 ~) o OPTiM Cloud IoT OS / LANDLOG (2017 ~) o Tech lead of digital identity o likes “eyJ...” o Member of OpenID Foundation Japan o Enterprise Identity Working Group Phase 3 (2016 ~) o KYC Working Group (2019 ~) o Rubyist ♥ Profile
3. Copyright © OPTiM Corp. All Right Reserved.
4. Copyright © OPTiM Corp. All Right Reserved. 4  AI/IoT Platform を作るための Platform  Data Hub となる API Sets や Device Control のAPI Setsと、 それらを操作する標準アプリを提供  大規模な開発体制のため、 microservice architecture を採用 • コンテナは Kubernetes でオーケストレーションしている  用途に応じて複数の開発言語 / フレームワークが 使い分けられている • 例) • App: Vue.js + Node.js • Core API: golang • IdM/IAM: Ruby on Rails OPTiM Cloud IoT OS
5. Copyright © OPTiM Corp. All Right Reserved. Image: マイクロサービスとは – RedHat https://www.redhat.com/ja/topics/microservices/what-are-microservices
6. Copyright © OPTiM Corp. All Right Reserved. 6
7. Copyright © OPTiM Corp. All Right Reserved. 7  API をどうやって守るか • API を実行できる = そのアプリケーションに、ユーザーのデータが渡る • 誰でも API を呼べていいわけではない • ユーザーが認めたアプリケーションにのみ、データを渡せなければならない  各リソース（データ）をどうやって守るか • ユーザーのリソースは、誰でもアクセスできていいわけではない • 自分専用のものもあれば、会社の特定の人だけ見れるものもある • 一時的に、誰かにアクセス権限を渡したいこともある • 誰がそのリソースにアクセス出来るかを、制御する仕組みが必要  各アプリケーションの認証をどうするか • 標準アプリの場合、ユーザー情報は直接持っていない • ユーザー認証 (Context の識別) が出来ない • 3rd Party アプリの場合でも、Cloud IoT OS とシングルサインオン出来る方が ユーザーの使い勝手が良い & クレデンシャルを持たなくて良い 認証・認可・権限制御
8. Copyright © OPTiM Corp. All Right Reserved. 8  API をどうやって守るか • API を実行できる = そのアプリケーションに、ユーザーのデータが渡る • 誰でも API を呼べていいわけではない • ユーザーが認めたアプリケーションにのみ、データを渡せなければならない  • • • •  • • • 認証・認可・権限制御
9. Copyright © OPTiM Corp. All Right Reserved. 9 3rd Apps 大雑把なイメージ API Service 標準App
10. Copyright © OPTiM Corp. All Right Reserved. 10
11. Copyright © OPTiM Corp. All Right Reserved. https://tools.ietf.org/html/rfc6749
12. Copyright © OPTiM Corp. All Right Reserved. 12 OAuth とは、  リソース所有者が  アプリケーションに対して  リソース所有者の代わりに、対象のリソースへアクセスするための  アクセス許可（認可）の手段を提供する ための、委譲プロトコル Protect API with OAuth
13. Copyright © OPTiM Corp. All Right Reserved. 13 Overview OAuth 2.0 Resource Access w/ Access Token Use App Authorize an app
14. Copyright © OPTiM Corp. All Right Reserved. 14  認証・認可を行うサービスと、 APIサーバーは別の service • 別サービスの払い出した Access Token を受け入れなければならない • 正当に発行されたものなのか、有効期限内なのか、etc...  考えられうる対応方法 • Shared DB を使って、Access Token の管理DBごと共有する • API を使って、Authorization Server に問い合わせを行う（Token Introspection） • Access Token 自体に、情報を入れてしまう（Formatted access token） OAuth problems in microservices
15. Copyright © OPTiM Corp. All Right Reserved. 15 Shared DB Pros • 実装が容易 Cons • Shared DB が SPOF （Single Point Of Failure: 単一障 害点）となってしまう • 全てのサービスを同一ネットワーク内に配置し なければならない • Shared DB の変更が全 Resource Server に波及する
16. Copyright © OPTiM Corp. All Right Reserved. 16 Token Introspection Pros • 異なるネットワークに配置することが出来る Cons • Authorization Server の負荷が高くなり、 Resource Server のスケールに合わせて Authorization Server をスケールしないといけないため、リソースの 無駄が大きい • Authorization Server が SPOF （Single Point Of Failure: 単一障害点）となってしまう
17. Copyright © OPTiM Corp. All Right Reserved. 17 Formatted Access Token Pros • Resource Server 自身で Access Token の検証を行え るため、依存先がない（外部にSPOF がない） • Resource Server のトラフィックに合わせてスケー ルすれば良いため効率的なスケールアウトが行 える Cons • Access Token の Revoke が出来ない
18. Copyright © OPTiM Corp. All Right Reserved. 18
19. Copyright © OPTiM Corp. All Right Reserved. 19
20. Copyright © OPTiM Corp. All Right Reserved. 20 JSON Web Token
21. Copyright © OPTiM Corp. All Right Reserved. 21 OAuth in CIOS  Formatted Access Token を採用 • IoT 文脈では、大量のアクセスが想定されうるため、自立分散で動作できる方が望ましい  Access Token のフォーマットに JSON Web Token を採用 • 署名付きなので JWS  Access Token の署名に使う秘密鍵と対になる公開鍵はキャッシュ可能なため、検証の際に Authorization Server へ問い合わせる必要はない • キャッシュがない場合は、Authorization Server の提供するエンドポイントから取得 (JWK Set format)
22. Copyright © OPTiM Corp. All Right Reserved. 22 Access Token 各 API Server は、これらの値が 想定しているものになっているかを検証し リクエストバリデーションを行う
23. Copyright © OPTiM Corp. All Right Reserved. https://www.ietf.org/id/draft-ietf-oauth-access-token-jwt-02.txt 最近 draft 化されました (設計したときにはなかったので、準拠してはない)
24. Copyright © OPTiM Corp. All Right Reserved. 24  Microservices という意味では、今の所うまく行っている • 認可周りがボトルネックになる事象は起きていない  運用中にいくつかの issue が発生した  Access Token の検証 • iss/exp といった時刻に関する claim が、サーバー間での時刻ずれによって、うまく検証処理できないケー スが発生 • NTP は設定していたが、Hypervisor の stop the world を食らってしまった • 時刻を扱う場合、これらの時刻同期ずれを考慮に入れなければならない  Access Token の Lifetime 問題 • （formatted であるか否かに関わらず）Lifetime は本来可能な限り短いべきであるが、あまりその理解が進 んでいない現状 • Refresh token の積極的な活用と、Offline access への理解が求められる Review
25. Copyright © OPTiM Corp. All Right Reserved. 25