Upgrade to Pro — share decks privately, control downloads, hide ads and more …

OAuth vs microservices

5c097a7b75c8802b073774faa7276503?s=47 optim
October 24, 2019

OAuth vs microservices

5c097a7b75c8802b073774faa7276503?s=128

optim

October 24, 2019
Tweet

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