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