これまでに行った手順:
user_pool_client_id
user_pool_client_id
のユーザープールクライアント設定で、[Cognito User Pool]ボックスをオンにし、コールバックとしてhttps://localhost
を追加してURLをサインアウトし、[Authorization Code Grant]、[Implicit Grant]、および[許可OAuthスコープ "user_pool_domain
としましょうユーザー名/パスワードで新しいユーザーを作成する
今、私はうまく行くことができます:
https://{{user_pool_domain}}.auth.us-east-2.amazoncognito.com/oauth2/authorize?response_type=code&client_id={{user_pool_client_id}}&redirect_uri=https%3A%2F%2Flocalhost
これにより、ログインページが表示され、https://localhost/?code={{code_uuid}}
に戻るユーザーとしてログインできます。
次に、次のことを試します:curl -X POST https://{{user_pool_domain}}.auth.us-east-2.amazoncognito.com/oauth2/token -H 'Content-Type: application/x-www-form-urlencoded' -d 'grant_type=authorization_code&redirect_uri=https%3A%2F%2Flocalhost&code={{code_uuid}}&client_id={{user_pool_client_id}}'
ただし、これは以下を返すだけです:{"error":"unauthorized_client"}
トークンエンドポイントのドキュメント は、unauthorized_client
は、「クライアントはコード付与フローまたはトークンの更新が許可されていないため」と述べています。これは、クライアントがコード許可フローを使用できるようにするボックスをオンにしたため、混乱しています。
したがって、ユーザープールには末尾にスラッシュ(https://localhost/
)そして、その末尾のスラッシュは、すべてのコールバックURLで使用する必要があります。それからそれは働くことに決めます!
すべてが私には問題ないように見えます。 Authorizationヘッダーが欠落していることについて不平を言っているかもしれませんが、よくわかりません。あなたはいくつかのことを試すことができます:
1)このページ( https://docs.aws.Amazon.com/cognito/latest/developerguide/token-endpoint.html )によると、Authorizationヘッダーを送信する必要はありませんトークン要求ですが、おそらくまだ必要です。クライアントIDのみを渡すか(Authorization [クライアントID])、またはシークレットを構成して、許可[クライアントID:クライアントシークレット]を渡してみることができます)。このフローには、トークン交換を安全に処理できるサーバー側コンポーネントがあるため、通常、認証コードフローにクライアントシークレットを使用することは理にかなっています。
2)代わりにImplicit Flowを使用して、機能するかどうかを確認してください。 Implicit Flowは、サーバー側コンポーネントのない単一ページのアプリに適しています。そのため、クライアントシークレットは必要ありません。