OAuth vs microservices - Speaker Deck

Slide 1

Slide 1 text

Slide 2

Slide 2 text

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

Slide 3

Slide 3 text

Slide 4

Slide 4 text

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

Slide 5

Slide 5 text

Slide 6

Slide 6 text

Slide 7

Slide 7 text

Copyright © OPTiM Corp. All Right Reserved. 7  API をどうやって守るか • API を実行できる = そのアプリケーションに、ユーザーのデータが渡る • 誰でも API を呼べていいわけではない • ユーザーが認めたアプリケーションにのみ、データを渡せなければならない  各リソース（データ）をどうやって守るか • ユーザーのリソースは、誰でもアクセスできていいわけではない • 自分専用のものもあれば、会社の特定の人だけ見れるものもある • 一時的に、誰かにアクセス権限を渡したいこともある • 誰がそのリソースにアクセス出来るかを、制御する仕組みが必要  各アプリケーションの認証をどうするか • 標準アプリの場合、ユーザー情報は直接持っていない • ユーザー認証 (Context の識別) が出来ない • 3rd Party アプリの場合でも、Cloud IoT OS とシングルサインオン出来る方がユーザーの使い勝手が良い & クレデンシャルを持たなくて良い認証・認可・権限制御

Slide 8

Slide 8 text

Slide 9

Slide 9 text

Slide 10

Slide 10 text

Slide 11

Slide 11 text

Slide 12

Slide 12 text

Slide 13

Slide 13 text

Slide 14

Slide 14 text

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

Slide 15

Slide 15 text

Copyright © OPTiM Corp. All Right Reserved. 15 Shared DB Pros • 実装が容易 Cons • Shared DB が SPOF （Single Point Of Failure: 単一障害点）となってしまう • 全てのサービスを同一ネットワーク内に配置しなければならない • Shared DB の変更が全 Resource Server に波及する

Slide 16

Slide 16 text

Copyright © OPTiM Corp. All Right Reserved. 16 Token Introspection Pros • 異なるネットワークに配置することが出来る Cons • Authorization Server の負荷が高くなり、 Resource Server のスケールに合わせて Authorization Server をスケールしないといけないため、リソースの無駄が大きい • Authorization Server が SPOF （Single Point Of Failure: 単一障害点）となってしまう

Slide 17

Slide 17 text

Copyright © OPTiM Corp. All Right Reserved. 17 Formatted Access Token Pros • Resource Server 自身で Access Token の検証を行えるため、依存先がない（外部にSPOF がない） • Resource Server のトラフィックに合わせてスケールすれば良いため効率的なスケールアウトが行える Cons • Access Token の Revoke が出来ない

Slide 18

Slide 18 text

Slide 19

Slide 19 text

Slide 20

Slide 20 text

Slide 21

Slide 21 text

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)

Slide 22

Slide 22 text

Slide 23

Slide 23 text

Slide 24

Slide 24 text

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

Slide 25

Slide 25 text