What?
例えば、YouTubeのプレイリストへの動画登録を自動化することを考える。この場合、OAuth2 認可コードフローで、自動化するアプリケーションにプレイリスト所有者のアカウントへのアクセスを認可させる必要がある(※1)。
ただし、発行されるアクセストークンは、一般的に有効期限が短い。その都度認可する必要があるのでは、自動化するメリットがない。よって、アクセストークンと一緒に発行されたリフレッシュトークンを永続化し、アプリケーションから読み出して利用できるようにする。
この記事では、Web APIの認可コードフローのリフレッシュトークンを発行・保存するだけのWebアプリケーションの構成について説明する(※2)。
(※1)認可を自動化することは原則できない。それはアプリにユーザID, パスワードを渡すことになるので認可コードフローの思想に反する（例え自分のアカウントのみを利用する想定であっても）。真っ当なWebアプリケーションは認可画面にbot対策が仕掛けられているはずである。よって、「自動化」とは書いたが、認可は手動で行う必要があるので、「半自動化」である。
(※2)利用したいAPIがクライアントクレデンシャルフローであれば、ユーザの認可は不要なので、Webアプリケーションを構築する必要はない。また、アプリがWebアプリケーションであれば、そのWebアプリケーションを使って認可をすればいいので、別途Webアプリケーションを構築する必要はない。アプリがバッチ処理などのクライアントの手を介さないものであれば、今回の構成は有効であると考えられる。
システム構成図(例)
AWSで構成した。例は下記の通りである。
赤字がWebアプリケーション部分である。アクセス頻度はリフレッシュトークンの有効期限次第であり、これは一般的には長いので、極めて少ない。よって、コストが最小となるように、API Gateway + Lambda構成とした。コスト面を気にしなければ、他の構成(EC2やECS+ALB)でも問題ない。
ストレージは、WebAPIを利用するアプリがRDSを使っているため、そのRDSを使い回しており、別のリソースでも問題ない。
必要なもの
- 認可サーバのリダイレクト先としてブラウザからのアクセスを認可コードを受けられるリソース(図ではAPI Gateway)
- トークンエンドポイントにリクエストできるリソース(図では左のLambda)
- ストレージ(図ではRDS)
- ストレージにアクセスできるリソース(図では右のLambda)
今回、Lambdaが2つあるのは、以下の制約からである。
(1)LambdaからRDSにアクセスするにはLambdaをVPCに配置する必要がある
(2)一方、VPCに配置したLambdaはインターネットにアクセスできないので、トークンエンドポイントにアクセスするには別のLambdaを定義する必要がある
EC2やECSであればリソースを2つ用意する必要はないし、ストレージがRDSでなく、DynamoDBのようなリージョンサービスであれば、普通のLambdaからアクセス可能である。