API Gateway + Lambda + Cognitoユーザープールを使用して単純なREST APIを構築することを検討しています。
APIは2つの方法で使用されます。 1つ目は、基本的なWebアプリ(CloudFront + S3でホストされている)をサポートすることです。 Webアプリケーションの認証は、ホストされたCognitoサインイン/サインアップフローを使用し、正常に機能しています(ユーザープールオーセンティケーターを使用するようにAPI Gatewayをセットアップします)。
2番目の方法は、顧客がREST APIを使用してシステムと通信することです。
例として、クライアントはWebアプリを使用してワークフローを構成し、APIを使用してそのワークフローを呼び出すことができます。
バックエンドサービスで使用するためにAPIを認証するための推奨される方法は何ですか?
従来、この目的にはAPIキーとシークレットトークンを使用することを期待していました。 API GatewayインターフェースでAPIキーを作成することに問題はありませんが、それを特定のユーザーにリンクする方法がわかりません。また、APIキーと一緒にシークレットトークンを指定する方法もわかりません。
そして、上記が可能であると仮定すると、WebアプリケーションにJWTベースのアプローチを使用し、顧客が使用するAPIキー+シークレットトークンを使用できるように設定するにはどうすればよいでしょうか。
編集:さらに、アプリクライアントにはIDとシークレットがあることに気付きました。これらは、3番目のAPIベースの認証に使用することを目的としていますか(他のシステムでAPIアクセス用のアプリを作成する方法と同様)?ソフト制限ですが、ユーザープールごとに25の制限があるため、私は少し懐疑的です...
私はこれに対する答えを自分で探していました、そして私の検索は私をあなたの質問に導きました。あなたがよく知られた鍵/秘密のアプローチを利用したいと仮定して、私はあなたに私の研究から私の最良の答えを与えるでしょう。たぶん他の人がより良いアプローチを提供することができます。
基本的に、アプローチは次のとおりです。
REST APIをCognitoトークンを使用するように構成すると、REST APIを API GatewayによるCognitoのサポート と直接統合できます。 =。
この全体の最大の頭痛の種は、たとえば、登録ユーザーがAPIアカウントを要求し、それらのアカウントを管理するためのサポートピースと、追加のヘルパーを作成する必要があることだと思いますRESTトークン交換のエンドポイント。さらに、クライアントはキー/シークレットとトークンを追跡し、トークンまたは資格情報をいつ提供するかを知るためにクライアント側のロジックを追加する必要があります。
APIゲートウェイとCongitoを使い始めたとき、 https://github.com/awslabs/aws-serverless-auth-reference-app をたくさん参照し、統合のデモンストレーションに非常に役立つことがわかりました。異なるAWSコンポーネント間。
私があなたを正しく理解しているなら、あなたはあなたのAPIへのプログラムによるアクセスのために「長命のAPIキー+シークレット」を作成したいですか?
私にはまさにこの必要性があり、悲しいことにそれは不可能であるように思われます。キーが有効であることができる最長は1時間です。 10年間有効な更新トークンを持つことができます。 https://docs.aws.Amazon.com/cognito/latest/developerguide/limits.html
私は現在、これに対するエレガントな解決策を探しています。あなたが解決策を見つけたのか、それともあなたが自分で解決策を見つけたのか、聞いてみたいと思います。