一時Cognitoを死ぬほど調べたことがあった(AngularアプリにCognitoのユーザ認証を利用した)ので、自称僕よりCognito詳しい人いないマンなんですが、まだまだ知らないことがありました。
「Client Credentials Grant」ってやつですが、Cognitoには他にも「何とかGrant」はあります。
どちらかというと、本来のCognitoの用途とは離れているんですが、知らないことがあるのは気持ち悪いので調べてみました。
そもそもClient Credentials Grantって？
そもそもな話、Cognitoを使ったことがある人なら分かるのですが、Cognitoは「ユーザ認証のためのサービス」と言っても過言ではありません。
Cognitoを使うことで、Cognitoのユーザ認証を通過したユーザだけがAPIを叩けるように認証設定ができたりします。
が、ユーザ認証は必要ないがAPIに認証設定をかけたいケースはそれなりにあるはずです。
例えば、AサービスからBサービスのAPIを叩く場合、ユーザ認証は不要だがAPIの認証自体はかけたいなど。
こんな場合に利用するのが「Client Credentials Grant」だと思ってもらえればOKです。
Client Credentials Grantを使うための準備
まあ、なんでも実際に使ってみるのが良いということで触ってみましょう。
左メニューの「リソースサーバ」を選択し、「リソースサーバの追加」から上記のように設定します。
リソースサーバはとりあえず登録しないといけないので文句言わずにやりましょう。
こんな感じでできたかと思います。
左メニューの「アプリクライアント」から上記のような設定でアプリクライアントを作成します。
左メニューの「アプリクライアントの設定」をクリックし、上記のように設定します。
「許可されているOAuthフロー」の「Client credentials」にチェックを入れると、「許可されているカスタムスコープ」に「test_resource/test」が表示されるのでチェックを入れます。
あと、後々使うのでドメインの登録を済ませておきます。
左メニューの「ドメイン名」をクリックし、適当なドメイン名を設定します。
Client Credentials Grantを使ってみよう
詳細情報はこちらに記載されています。
諸々の情報をPOSTしてトークン情報を取得するので、今回はRestlet Clientを使用します。
⇒POSTManとかでも勿論可能。
こんな感じでPOSTします。
| METHOD | POST |
|---|---|
| URL | https://<あなたのドメイン名>.auth.ap-northeast-1.amazoncognito.com/oauth2/token |
| Content-Type | application/x-www-form-urlencoded |
| Authorization | Basic <トークン> ※トークンは「アプリクライアントID ＋ “:” + アプリクライアントのシークレット」をBase64化したもの。 「https://hogehoge.tk/tool/」とかで変換できます。 |
| grant_type | client_credentials |
| scope | 許可されているカスタムスコープで選択した内容。 ※今回であれば「test_resource/test」。 |
|
1 2 3 4 5 |
{ "access_token": "eyJraWQiOiJLZUNERWhSbUdqTkNDNWpMaTQ2aElmUU5xUlwvZ0w5ZzJjaytiSUliRnp2az0iLCJhbGciOiJSUzI1NiJ9.eyJzdWIiOiI3bW9ucTl2cWU4MXU3b3BkNmIyYm44ZGlwMyIsInRva2VuX3VzZSI6ImFjY2VzcyIsInNjb3BlIjoidGVzdF9yZXNvdXJjZVwvdGVzdCIsImF1dGhfdGltZSI6MTU4Mjk3Nzg1OSwiaXNzIjoiaHR0cHM6XC9cL2NvZ25pdG8taWRwLmFwLW5vcnRoZWFzdC0xLmFtYXpvbmF3cy5jb21cL2FwLW5vcnRoZWFzdC0xX0hzSFZrWWNYUiIsImV4cCI6MTU4Mjk4MTQ1OSwiaWF0IjoxNTgyOTc3ODU5LCJ2ZXJzaW9uIjoyLCJqdGkiOiIwNzE0YzRjNy1mMTdiLTRlZjEtYTBhOS01NmRlYjllM2JhZTciLCJjbGllbnRfaWQiOiI3bW9ucTl2cWU4MXU3b3BkNmIyYm44ZGlwMyJ9.S7_L38JKoR6wvmRDMVg5iv1NDong3V6CpRpZvz8gS9omB159BMwQ_o46WBa0bDmkPai7JvqXT-eGz9ghZsU8i79bOhNmCIkivthtrLCoz2ICFAQJ_LQAmhbx756CkY-uaihHdWYWpkbwfFxhKM1e0GsMh3cpe0ncMe3esZa66ecCtznsZ3FEmEC4JCE_h_DLMIrPlMZuPkHDa1DNe5RyO31crVZd79mon1mGBQ0lS90SoHGOzScRAkRZ_atfAL84b_fXQY6lTVadtN0f6lSVMpZZ5fVEhdERNBU9XP0bCESi8IXJ_reecfN5uXzDNxQPjMogUr24mx0aYF3dL9i3ZA", "expires_in": 3600, "token_type": "Bearer" } |
取れた！！POSTした結果は上記の通りです。
ちなみに、「invalid_client」などのエラーが返ってくる場合は大体トークンがミスってると思います。
その辺りの情報も、こちらの下の方に詳細が載っています。
API Gatewayとかの設定に使えるよ
当たり前ですが、API Gatewayに認証の設定を行えば、先ほどのトークンを認証情報として利用できます。
そこまでやりたかったんですが、僕のAWS環境にはまだAPI Gatewayがいない＆メンドクサイので、下記サイトを見てね。
まとめ
トークンのBase64化で「echo -n “【アプリクライアントID】:【アプリクライアントのシークレット】” | base64」を使ったんですが、これが正しくBase64化できておらず、なかなかに苦戦した。。
ではさいなら。