今後APIの体系をどうしていくか決める

[jacopen]

現在はDkがAPIを担っているのでDkのURL=APIになるが、今後コンポーネントを分けていくにあたって

• LambdaのViewerCount
• k8s上のDk
• ????のChat

などなど、さまざまな場所にさまざまな形でAPIが実装されることになる。
こうなると、APIの認証や接続先が複雑になってフロントエンドやコマンドツールの実装が困難になっていく可能性が高い。
そのため、このあたりをどうしていくか検討する。

• API Gatewayで集約する
• JWT認証もこっち？
• ReviewApp向けにどうやってAPIエンドポイントを動的に作るか

などなど

[jacopen]

API Gateway周りを調査中。

$default でマッチしなかったリソースをリバースプロキシ的にDkに向けることは可能。

[jacopen]

うーん、これじゃないな
https://docs.aws.amazon.com/ja_jp/apigateway/latest/developerguide/http-api-jwt-authorizer.html

[jacopen]

とりあえずこんなステップで導入を進めていこうと思う

[jacopen]

バックエンドがLambdaであれば、Lambda統合によってJWTクレームにアクセスできるようだ。
JSON.stringify(event.requestContext.authorizer.jwt.claims.name) ただHTTP統合の場合はよく分からないし、ドキュメントにも見つからない。
https://dev.classmethod.jp/articles/api-gateway-jwt-auth-azure-ad-craim/

[jacopen]

リクエストをダンプするSinatraアプリを作って、API Gateway経由で動きを試してみた。

まずは↑↑の導入ステップ3であるJWTによるAuhotization Code Flowを想定した動作を試した。
Auth0を使ったCustom AuthorizerでちゃんとJWTを検証しアクセスすることが出来た。(不正なJWTだと401になった)

バックエンドとしてはLambda統合のようにはいかず、クレームの情報を得る方法はなさそうだ。
ただ設定されたAutorization Headerはそのまま渡されているため、バックエンド側でも渡されたID Tokenを読んでそこから必要な情報を抽出する形にすればいいかなー。

[jacopen]

よく考えたらリバースプロキシとして使う作戦、Cookieでの認証が出来ないからダメでは？？？？？？