Lambdaを使用し、AWS API Gatewayを介してアクセスする、さまざまなフロントエンド(モバイルアプリとウェブアプリ)と単一のAPIバックエンドでアプリを構成しています。
Cognitoを使用してユーザーを認証および承認することを計画しているので、APIゲートウェイといくつかのAPIメソッドにCognitoユーザープール認証を設定しました。
このようなアーキテクチャでは、私のアプリ(iOSやVue.jsアプリなど)がOAuthの観点から見たクライアントアプリケーションであり、APIゲートウェイのバックエンドがリソースサーバーであることが理にかなっています。 このAuth0フォーラムの投稿 に基づいているため、クライアントアプリでIDトークンを使用し、アクセストークンを渡してAPI Gatewayリソースを承認する必要があることは明らかです。
コグニートを叩いた時/oauth2/authorize
エンドポイントを使用してアクセスコードを取得し、そのコードを使用して/oauth2/token
エンドポイント、3つのトークン-アクセストークン、IDトークン、および更新トークンを取得します。これまでのところ、私は私が必要とするものを持っているはずなので、良いです。
ここで問題が発生しました。APIGateway Cognito User Pool Authorizerコンソールのテスト機能を使用して、IDトークンを貼り付け、それを渡します(画面上のトークンのデコード)。しかし、アクセストークンに貼り付けると、401 - unauthorized
。
私のCognitoセットアップでは、Authorization Code Grant
フローのみ、email
およびopenid
スコープ(これは、少なくともこれらのチェックなしで保存しようとするとエラーが発生するため、Cognitoで許可されている最小値のようです)。
API Gatewayでアクセスコードを使用してリクエストを承認するには、特定のスコープを追加する必要がありますか?もしそうなら、これらはどこに設定されていますか?
それとも何か不足していますか? API Gatewayでは、IDトークンをCognitoユーザープール認証でのみ使用できますか?
Idトークンで機能するものと同じ認証でアクセストークンを使用できますが、ユーザープールとAPIGで実行する追加の設定がいくつかあります。
この追加のセットアップが行われた場合でも、組み込みのオーソライザーテスト機能をアクセストークンで使用することはできず、IDトークンのみを使用できます。 AWSの典型的な80%ソリューション!
アクセストークンを使用するには、App Integration -> Resource Servers
の下のユーザープールにリソースサーバーを設定する必要があります。何を使用してもかまいませんが、識別子に<site>.com
を使用し、1つのスコープが呼び出されていると想定しますapi
。
APIGのメソッドに移動して、メソッドのMethod Request
を入力する必要はありません。これがidトークンでテストされたオーソライザーですでにセットアップされていると想定して、次に<site>.com/api
をSettings -> OAuth Scopes
セクションに追加します。
OAuthスコープを追加するだけで、トークンはアクセストークンである必要があり、IDトークンは受け入れられなくなります。
はい。APIGatewayは承認にidTokenのみを使用します。
ユーザーが正しい認証情報を入力すると、IDプロバイダーがアクセスコードを提供し、ユーザーが正しい認証情報を入力したことを承認します。このアクセスコードは、特定のユーザーの/oauth2/token
エンドポイントからidTokenとrefreshTokenを取得するためだけにクライアントによって使用されます。以降のすべての呼び出しでは、AuthorizationヘッダーでidTokenのみが使用されます。
ユーザートークンを取得すると、そのアクセスコードでも有効期限が切れます。