一般的なREST API認証方法の説明

自動化とオーケストレーションを実装する際には、API における認証の仕組みを理解することが重要です。環境内のほとんどの製品には、何らかの認証メカニズムが備わっていると考えられます。これらの API との通信を自動化するには、様々な認証方法のニュアンスと違いを理解する必要があります。このブログ記事では、3 つの異なる API 認証方法を詳しく説明することで、理解を深めていただくことを目的としています。.

ユーザー名とパスワードの認証

REST APIで最もよく使われる認証方法の一つは、ユーザー名とパスワードによる認証です。ユーザー名とパスワードを使用する認証方法はいくつかありますが、最も一般的なのはHTTPベーシック認証です。APIに慣れた方であれば分かりやすいですが、初心者にとっては仕組みや使い方を理解するのが難しい場合があります。.

あたり RFC2617, ベーシック認証を用いたHTTPリクエストを行うには、ユーザー名とパスワードをコロンで区切ったBase64エンコードされた文字列が必要です。この文字列の先頭に「Basic」という文字列と1つのスペースが付加されます。これをもう少しわかりやすくするために、次の例を見てみましょう。

ユーザー名: first.last

パスワード: my5uper5ecretP@ssw0rd

上記の例のようなユーザー名とパスワードがあるとします。これらをAPIへのHTTPリクエストの一部として使用するには、まずコロンで結合する必要があります。

姓:my5uper5ecretP@ssw0rd

それが終わったら、Base64でエンコードする必要があります。Pythonでは次のように実行できます。

base64をインポート

auth_string = base64.b64encode(b':'.join(('first.last'.encode('latin1'), 'my5uper5ecretP@ssw0rd'.encode('latin1')))).strip()

auth_string 変数を出力すると、次の値が返されます。

b'Zmlyc3QubGFzdDpteTV1cGVyNWVjcmV0UEBzc3cwcmQ='’

エンコードされた文字列ができたら、この変数の先頭に認証方法文字列（Basic）を追加します。変数文字列全体は以下のようになります。

基本 Zmlyc3QubGFzdDpteTV1cGVyNWVjcmV0UEBzc3cwcmQ=

この文字列が作成されると、HTTPリクエスト内の特定のHTTPヘッダーに追加されます。このヘッダーは特別なもので、認証に使用されます。まだお分かりでなければ、このヘッダーはAuthorizationと呼ばれます。便利ですよね？

基本認証を使用する cURL コマンドの例を次に示します。

AUTH=$(echo -ne "$BASIC_AUTH_USER:$BASIC_AUTH_PASSWORD" | base64 --wrap 0) curl \ --header "Content-Type: application/json" \ --header "Authorization: Basic $AUTH" \ --request POST \ --data '{"key1":"value1", "key2":"value2"}' \ https://example.com/

JWT認証

JWT（JSON Web Token）認証は、以下の方式に基づいたトークン認証の一般的な形式です。 RFC 7519. JWT認証は、ヘッダー、ペイロード、署名という3つの主要な部分で構成されます。これらの各部分はBase64エンコードされ、認証のためのHTTPリクエストとともに送信されます。.

JWTクレームセットは、JSONオブジェクトで指定された1つ以上のクレームで構成されます。クレームセット内の各クレームには、一意のキーと対応する値があります。例えば、JWTクレームセットの典型的な構造は以下のとおりです。

{ “iss”： “josh”, “exp”： 1617221146, “https://api.mycompany.com/some...”： true }

各キーと値は一意である必要があり、クレームセット内で作成される個々のクレームとみなされます。指定された各キーは任意であり、RFC標準では必須ではありません。つまり、JWT認証におけるクレームセットの構造は、使用するAPI / サービスによって異なります。.

ヘッダーと署名の値と同様に、JWTクレーム（ペイロード）を定義すると、Base64エンコードされます。これらの値は以下でテストできます。 https://jwt.io 同じように。.

OAuth2認証

OAuth2認証は、同じエンドポイントに対して様々な認証方法（フロー）をサポートしているという単純な理由から、非常に人気が高まっています。これにより、開発者は、Webアプリケーション、デスクトップアプリケーション、モバイルデバイスなど、様々な状況での認証を可能にする堅牢なサービスを構築できます。それぞれのエンドポイントごとに全く異なる認証メカニズムをサポートするのではなく、いくつかの詳細を変更するだけで済みます。.

OAuth2 認証の概念を理解しやすくするために、次の 4 つのコア コンポーネントを示す図を作成しました。

1. アクセスを必要とするユーザーまたはシステム

2. 認可を担当するサーバー

3. 認可サーバー経由でアクセスを許可されたアプリケーション

4. アプリケーションはその承認に基づいてデータにアクセスします

OAuth2 についてさらに詳しく知りたい場合は、OAuth2 についてさらに詳しく説明した 3 部構成のシリーズをご覧ください。

• パート1: エンドポイントとアプリケーションの種類

• パート2: アプリケーションの登録

• パート3: Microsoft Graph APIの使用

認証タイプを見ると、OAuth2 と JWT は Basic よりも安全であり、API を使用する場合、特に EDR、SIEM などの製品を扱う場合には、これら両方に遭遇する可能性が高くなります。.

REST API 認証には、上記に挙げた方法のバリエーションをはじめ、さまざまな種類がありますが、API で使用される最も一般的な 3 つの認証方法について理解していただけたと思います。.