はじめに
こんにちは!カスタマーサクセス本部の加治屋です。
本ブログでは、Amazon Cognitoの「Client Credentials(クライアントクレデンシャル)」フローを利用して、「マシンツーマシン(M2M)」認証を実装する手順を解説します。
今回は実践的な構成として、Amazon Cognitoで発行したトークンを使って、Amazon API Gatewayにセキュアにアクセスする構成を構築していきます。
事前準備
API Gatewayの作成
検証用のAPI Gatewayを作成します。

作成したAPIを選択し、ナビゲーションペインの「リソース」をクリックします。
デフォルトで「 /(ルート)」というリソースが用意されているため、今回はこの 「/」 をそのまま使います。
「/ 」を選択した状態で「メソッドの作成」をクリックし、GET メソッドを選択の上、統合タイプを「Mock」 に設定してメソッドを作成します。
(※今回は認証機能の確認を手軽に行うためにMockを選択していますが、実際のシステムでは用途に応じた統合タイプを選択してください。)

メソッドが作成できたら、変更を反映させるためAPIをデプロイします。
「新しいステージ」を選択し、ステージ名に「test」など任意の名前を入力し、デプロイします。

デプロイが完了したら、ステージの画面にある「URL を呼び出す」という項目にあるURLをコピーしてアクセスできるかテストしてみます。 今回は「マシンツーマシン(M2M)認証」がテーマなので、ターミナルを開き、プログラムからの呼び出しを想定して curlコマンドでアクセスを行います。
# 通信の成功ステータスが分かりやすいように、-i オプションをつけて実行する。 $ curl -i https://xxxxxxxxxx.execute-api.ap-northeast-1.amazonaws.com/test HTTP/2 200 x-amzn-requestid: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx x-amz-apigw-id: xxxxxxxxxxxxxxx= content-type: application/json content-length: 0 date: Thu, 19 Feb 2026 12:13:46 GMT
上記のように、1行目に HTTP/2 200(または HTTP/1.1 200 OK) が返ってくれば、APIへのアクセスは成功しています
(※Mockのデフォルト動作が「空のページを返す」ため本文はありませんが、エラーメッセージが出ていなければ問題ありません)
現時点では「誰でも(どんなシステムからでも)アクセスできる状態」です。 このAPIにCognitoを使って認証を実装していきましょう。
Cognitoを作成する
ユーザープールの作成
事前準備が完了したら、さっそくCognitoの作成を始めていきます。
まずCognitoのコンソールを見ると、「ユーザープール」と「IDプール」という2つの機能があります。
それぞれの役割は以下の通りです。
- ユーザープール:「認証」を担当。ユーザーの登録やログイン機能、ユーザー名簿の管理を行う。
- IDプール:「認可」を担当。ログインしたユーザーに「AWSのサービス(S3など)を直接操作する権限」を与える。
今回は「API Gatewayにアクセスするためのログイン機能(認証)」を作りたいので、「ユーザープール」 を作成します。
「アプリケーションタイプ」では「Machine to Machineアプリケーション」を選択し、任意のアプリケーション名を入力します。
入力を終えて、「ユーザーディレクトリを作成する」を押すと、以下の画面に遷移しますが、この画面では特に操作の必要はないため「概要に移動」をクリックします。
するとユーザープールの概要画面に移動します。
このときユーザープールにはAWSが自動で作成した名前がつけられているため、画面右上の「名前変更」をクリックし判別しやすい任意の名前に変更することをおすすめします。

これでCognitoの作成は完了です!
【補足】運用に合わせたカスタマイズについて
今回は検証用のため、AWSが自動生成してくれた設定をそのまま使用しますが、実際の運用フェーズでは以下のようなカスタマイズを行うことも可能です。
左側メニューの「ブランディング」>「ドメイン」を開くと、現在の設定状況が確認できます。

- カスタムドメインの設定
自動生成されたCognitoドメイン(https://ap-northeast-〇〇...)ではなく、自社で取得した独自ドメイン(例:auth.example.com)をトークン発行用の窓口として設定できます。本番環境などでURLを統一したい場合に使用します。 リソースサーバー名の変更
デフォルトでは「Default M2M Resource Server - 〇〇」といった名前が割り当てられますが、「編集」ボタンから、システム名など管理しやすい任意の名前に変更することが可能です。カスタムスコープの追加
自動生成では read というスコープが用意されますが、任意のスコープ名に変更することや用途に応じて新しくスコープを追加することも可能です。
トークンの発行テスト
では、実際にトークンが発行できるかをテストしてみましょう。
アプリケーションクライアントの画面内の「Quick Setup(クイックセットアップ)」ガイドを開くと、すぐに使える curlコマンドのサンプルが用意されています。
ここには、自動生成されたドメインやクライアントID、default-m2m-resource-server-XXXX/read といったカスタムスコープがすでに組み込まれています。
重要な機密情報であるクライアントシークレットはコマンドに組み込まれていないため、自分でコピーし、
コマンドの準備ができたら、ターミナルで実行してみましょう。
$ curl -X POST https://ap-northeast-xxxxxxxx.auth.ap-northeast-1.amazoncognito.com/oauth2/token \
-H "Content-Type: application/x-www-form-urlencoded" \
-d "grant_type=client_credentials&client_id=<クライアントID>&client_secret=<クライアントシークレット>&scope=default-m2m-resource-server-xxxx/read"
# 実行結果
{"access_token":"eyJraWQiOiJtaDJGZW5SbW5INHpTcUZ...(中略)...Q37w","expires_in":3600,"token_type":"Bearer"}
上記のようにaccess_tokenを含むJSONが返ってくれば成功です。
API Gateway と連携させる
Cognito 側でトークンを発行できるようになったので、次はこのトークンを使って API Gateway を保護する設定を行います。 やることは大きく分けて以下の3つです。
- オーソライザー(認証役)の作成
- API メソッドへの適用と「スコープ」の設定
- API のデプロイ
オーソライザーを作成する
まず対象のAPI Gatewayを選択した状態で、ナビゲーションペインにある「オーソライザー」をクリックします。
オーソライザーを作成をクリックし、以下のように設定していきます。
- オーソライザー名:(任意の名前)
- オーソライザーのタイプ:「Cognito」を選択
- Cognito ユーザープール:先ほど作成したユーザープールを選択
- トークンのソース:「Authorization」と入力
(※HTTPの標準的な認証ヘッダー名に合わせて設定します)

APIメソッドへ適用させる
オーソライザーの作成が完了したら次は左側のナビゲーションペインから「リソース」を選択し、対象のリソース(/)の下にある GET メソッドをクリックします。
「メソッドリクエストの設定」タブの「編集」をクリックします。

編集画面が開いたら、以下の2箇所を設定して「保存」します。
- 認可:先ほど作成したオーソライザーを選択します。(※プルダウンに表示されない場合は画面をリロードしてください)
- 認可スコープ:Cognitoで自動生成されたカスタムスコープ(例:
default-m2m-resource-server-xxxx/read)を入力します。
【補足】認可スコープの正確な値の確認方法
ここの文字列を1文字でも間違えると認証エラーになってしまいます。以下のいずれかの方法で確認し、コピペすると確実です。
確認方法①:サンプルコマンドからコピーする
先ほどの「トークン発行テスト」で確認した curlコマンドの末尾、scope= の後ろの部分がそのまま使えます。
curl -X POST https://ap-northeast-xxxx...
-H "Content-Type: application/x-www-form-urlencoded" \
-d "grant_type=client_credentials&...中略...&scope=default-m2m-resource-server-xxxx/read" #←scope= の後ろをコピーする
確認方法②:Cognitoの管理画面から確認する
Cognitoコンソールの「ブランディング」>「ドメイン」>「リソースサーバー」の項目を開きます。
ここに記載されている 【リソースサーバーの識別子】/【カスタムスコープ名】 をスラッシュで繋げた文字列が正式な値となります。
APIをデプロイする
メソッドリクエストの認証にCognitoを使うよう設定できたので、変更を反映させるためAPIをデプロイします。 事前準備の際に作成したステージを選択し、「デプロイ」をクリックします。
これでAPIとの連携設定が完了しました!
動作確認
それでは最後に設定した認証機能が正しく動いているかテストしてみます。 事前準備のときと同じように、ターミナルから curlコマンドを使ってAPIを呼び出します。
① トークンなしでアクセスしてみる(失敗テスト)
まずは、トークンを持たない状態でAPIにアクセスし、弾かれることを確認します。
$ curl -i https://xxxxxxxxxx.execute-api.ap-northeast-1.amazonaws.com/test
# 実行結果
HTTP/2 401
x-amzn-requestid: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
x-amzn-errortype: UnauthorizedException
x-amz-apigw-id: xxxxxxxxxxxxxxx=
content-type: application/json
content-length: 26
date: Thu, 19 Feb 2026 12:51:29 GMT
{"message":"Unauthorized"}
事前準備のときは 200 OK が返ってきていましたが、今回は 401 Unauthorized(認証されていません) となり、アクセスが弾かれることが確認できました。
② トークンを含めてアクセスしてみる(成功テスト)
次に、Cognitoでトークンを発行し、そのトークンを使ってAPIにアクセスしてみます。
APIにトークンを渡すには、curlコマンドに -H "Authorization: <アクセストークン>"を追加します。
#まずはCognitoにアクセスし、トークンを取得する
$ curl -X POST https://ap-northeast-xxxxxxxx.auth.ap-northeast-1.amazoncognito.com/oauth2/token \
-H "Content-Type: application/x-www-form-urlencoded" \
-d "grant_type=client_credentials&client_id=<クライアントID>&client_secret=<クライアントシークレット>&scope=default-m2m-resource-server-xxxx/read"
# 実行結果
{"access_token":"eyJraWQiOiJtaDJGZW5SbW5INHpTcUZ...(中略)...EvGQ","expires_in":3600,"token_type":"Bearer"}
# 発行したトークンを Authorization ヘッダーに付与して実行する
$ curl -i -H "Authorization: Bearer eyJraWQi...(中略)...EvGQ" https://xxxxxxxxxx.execute-api.ap-northeast-1.amazonaws.com/test
# 実行結果
HTTP/2 200
x-amzn-requestid: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
x-amz-apigw-id: xxxxxxxxxxxxxxx=
content-type: application/json
content-length: 0
date: Thu, 19 Feb 2026 12:56:08 GMT
認証が通り、HTTP/2 200が返ってくることが確認できました!
これで、Cognito(Client Credentialsフロー)を利用した、API Gatewayの「マシンツーマシン(M2M)認証」の実装は完了です。
おわりに
今回は、システム間連携でよく使われる「Client Credentials」フローを利用して、API GatewayにM2M認証を実装してみました。 この構成を使えば、Lambdaやオンプレミスのバッチ処理など、様々なシステムから安全にAPIを呼び出すことができます。
少しでも皆さんのAWS構築の参考になれば幸いです。
最後まで読んでいただきありがとうございました!
加治屋 (記事一覧)
2024年度新卒入社
蕎麦が好きです