Share via

認証

  • [アーティクル]

REST 呼び出しを行うときは、適切に認証するためにいくつかの手順が必要です。 AZURE COMMUNICATION SERVICES SDK はこのプロセスを処理しますが、要求を手動で行うには自分で処理する必要があります。

認証の種類

Azure Communication Servicesには 3 種類の認証があり、さまざまな目的で使用されます。

  • SMS、ネットワーク トラバーサル、通話オートメーション、ID、およびアクセス トークン操作のアクセス キー認証。 アクセス キー認証は、信頼できるサービス環境で実行されているアプリケーションに適しています。
  • Azure AD 認証 アクセス キー認証と同様に適用されます。 アクセス制御はより細かく、Azure RBAC を活用します。
  • チャットと通話のユーザー アクセス トークン認証。 ユーザー アクセス トークンを使用すると、クライアント アプリケーションが Azure Communication Services に対して直接認証を行うことができます。 これらのトークンは、作成するサーバー側のトークン プロビジョニング サービス上で生成されます。 その後、クライアント デバイスに提供され、クライアント デバイスはそのトークンを使用して、チャットおよび通話のクライアント ライブラリを初期化します。

アクセス キー認証

アクセス キー認証は、エンド ユーザー アプリケーションによって要求が行われていない場合に使用されます。 信頼されたサービス環境内でこれらの要求を実行します。

この認証方法では、要求はクライアントによって生成された ハッシュベースのメッセージ認証コード (HMAC) を使用して署名されます。

作業を開始する前に、次のことを確認してください。

  • Azure Communication Services アクセス キー
  • Azure Communication Service エンドポイント
  • 呼び出す URL パスと HTTP 動詞
  • HMAC、SHA256 ハッシュを生成し、Base64 操作を実行できる開発環境。

これらの項目を取得したら、要求の署名を続行できます。

HTTP 要求への署名

  1. 次の値を使用できることを確認します。

    • HTTP 要求メソッド (例: GET または PUT)
    • RFC1123 標準に従った要求の協定世界時 (UTC) タイムスタンプ
    • HTTP 要求ホスト ( <authority> RFC2396 で指定されている URI コンポーネント)
    • SHA256 アルゴリズムを使用してハッシュされた HTTP 要求本文
    • HTTP 要求パス ( <path> および <query> RFC2396 で指定されたコンポーネントによって ? 連結)
    Verb=<http_method>
Timestamp=<current_datetime>
Host=<uri_authority>
ContentHash=SHA256(<request_body>)
URIPathAndQuery=<uri_path>?<uri_query>

  2. 次の方法で値を連結して、署名する文字列を構築します。

    StringToSign=Verb + "\n"
URIPathAndQuery + "\n"
Timestamp + ";" + Host + ";" + ContentHash

  3. 前の手順で作成した UTF-8 エンコード文字列の HMAC-256 署名を生成します。 次に、結果を Base64 としてエンコードします。 また、アクセス キーを Base64 デコードする必要もあります。 次の形式を使用します (擬似コードとして表示)。

    Signature=Base64(HMAC-SHA256(UTF8(StringToSign), Base64.decode(<your_access_key>)))

  4. 次のヘッダーを要求に追加します。

    x-ms-date: <Timestamp>
x-ms-content-sha256: <ContentHash>
host: <URIPathAndQuery>   
Authorization: "HMAC-SHA256 SignedHeaders=x-ms-date;host;x-ms-content-sha256&Signature=<Signature>"

要求を受信すると、サービスは署名とタイムスタンプを検証して、リプレイ攻撃を含む特定のセキュリティ攻撃から保護します。 さまざまなプログラミング言語で HTTP 要求に署名する方法については、 HMAC ヘッダー署名に関するチュートリアルを参照してください。

Azure AD Authentication

Azure AD 認証は、リクエスタが Azure RBAC セキュリティ プリンシパルである場合に使用できます。 セキュリティ プリンシパルには、ユーザー、グループ、サービス プリンシパル、またはマネージド ID を指定できます。

作業を開始する前に、次のことを確認してください。

  • Azure サービス プリンシパル
  • 呼び出す URL パスと HTTP 動詞

サービス プリンシパルを取得する方法については、「- Azure CLI から Azure Active Directory サービス プリンシパル アプリケーションを作成する」を参照してください。

サービス プリンシパルを作成したら、認証にシークレットの 1 つを使用して、ユーザーの作成、ユーザー アクセス トークンの発行、または SMS メッセージの送信のために Communication Services にアクセスできます。

要求でのセキュリティ プリンシパル資格情報の使用

セキュリティ プリンシパルの ID とシークレットを取得したら、それらを 'Authorization' ヘッダーに指定することで、REST API をAzure Communication Servicesする要求で使用できます。

authorizationHeaderValue = convertToBase64String(<security principal ID> + ":" + <secret of the security principal>)
Authorization="BASIC <authorizationHeaderValue>"

ユーザー アクセス トークン認証

ユーザー アクセス トークンを使用すると、クライアント アプリケーションは、特定のユーザーまたは ID としてAzure Communication Servicesに対して直接認証できます。

ユーザー アクセス トークンの生成/取得

ユーザー アクセス トークンは、信頼できる環境内で生成されます。 Azure Communication Services Identity SDK を使用して生成するのが最も簡単な方法です。 詳細については、「 ユーザー アクセス トークンの作成と管理」を参照してください。

要求でのユーザー アクセス トークンの使用

適切なユーザー アクセス トークンを取得したら、Azure Communication Servicesの REST API への要求に含めることができます。 そのためには、ベアラー HTTP 認証スキーム Authorization: Bearer <token>をAuthorization使用してヘッダー内に指定する必要があります。

参照

Azure Communication Services認証の詳細については、以下を確認することもできます。