Vonageサイレント認証のご紹介

ご注意ください： サイレント認証は現在ベータ版です。詳細は リリースをご覧ください。

Vonageは サイレント認証 をVerify APIに導入できることを嬉しく思います！Silent AuthenticationチャネルはVerify V2の一部として追加され、現在アルファ製品フェーズにあります。この記事では、Silent Authenticationとは何か、何をするのか、どのように使うのかを説明します。では、手始めに以下にお答えしましょう：

サイレント認証とは何か？

サイレント認証は、個人認証ワークフローで最近開発されたもので、携帯電話の 加入者識別モジュール(SIM)をIDとして使用し、キャリアの記録と照合して、番号が有効で本物であることを確認する。リクエストが検証されると、コンシューマー・ベンダー／クライアントは、ユーザーが認証を希望するたびに同じエンドポイントを叩くことができる。これは事実上、次のようになる： 携帯電話を 携帯電話をパスワードとして使う.

サイレント認証を使用する利点は何ですか？

ワンタイムパスワード(OTP）は、世界中で二要素認証のために広く使用されています。当社の Verify APIの事実上の主な用途は、顧客の SMS に送信された OTP を使用することです。しかし、ここで正直に言おう。 煩わしい.確かに、それはセキュリティの追加レイヤーである（これが必ずしも真実ではない理由については、まもなく説明する）。しかし、（eコマースのような）ワークフローにおける少ないクリック数やナビゲーションポイントに依存しているベンダーにとっては、フローを完了させる（つまり商品を購入する）ための抵抗を増やしていることになる。Eコマースでは通常、最も抵抗の少ない経路が必要とされるため、その観点からSilent Authenticationは、ログインやカートのチェックアウトのための余分なステップを完全に取り除きます。

セキュリティも懸念事項だ。2FAはユーザー・フローのクラックを極めて困難にするというのが一般的な誤解だが、これは以下の点を考慮していない。 SMSフィッシングは詐欺師が使用する非常に一般的な攻撃ベクトルであることを考慮していない。キャリアとモバイル・デバイスの間で認証を直接行うことで、フィッシングの脅威は取り除かれる。

デメリットは？

真の開発者のスタイルとして、ユーザー検証に関して「万能」なものはないことを指摘しなければ、私たちは正しい仕事をしているとは言えないだろう。エンジニアと同じように、トレードオフがあるのだ：

• サイレント認証は、ユーザーがモバイル・デバイスを必要とするという点で、SMS認証と共通の障害となる。統計によれば、欧米諸国のスマートフォン所有率はまもなく90％を超える勢いである（例えば、英国では人口の88％がスマートフォンを所有している）。例えばイギリスでは人口の88％がスマートフォンを所有している。統計によれば、欧米諸国におけるスマートフォンの所有率はまもなく90％を超えそうな勢いだが（例えば、英国の人口の88％がスマートフォンを所有している）、サービスの質や経済性が積極的な障害となる可能性のあるグローバルな視聴者は考慮されていない。

• ユーザーの携帯電話 はセルラーデータを有効にしておく必要がある。これは小さなステップだが、可能な限りシンプルでありたいプロセスにおいて、余分な複雑さであることに変わりはない。

サイレント認証Verifyリクエストの作り方

同期と非同期の統合

Silent Authenticationを実装する同期的な方法をお見せするが、どちらもできるに越したことはない。この同期的な方法は、デバイスクライアントが一連の呼び出しを完了させることに依存しているが、何も変更することなく非同期ワークフローを使用することができる。ワークフローのすべての部分は、アプリケーションセットアップで選択したURLへのWebhookコールバックにも含まれている。

それでは早速、synchronousの実装を始めよう。まず最初に、処理を開始するために呼び出しを行う：

スロットル制限にヒットしておらず、認証トークンが正しければ、HTTPレスポンスに 202レスポンスが返されます。 request_idと check_url:

{
  "request_id": "c11236f4-00bf-4b89-84ba-88b25df97315",
  "check_url": "https://api.nexmo.com/v2/verify/31eaf23d-b2db-4c42-9d1d-e847e75ab330/silent-auth/redirect"
}

この check_urlは処理を続行するためのリンクなので、クライアント側のコードでそれを実行するようにします。このリンクをたどると、ターゲット・デバイスが使用している地域とキャリアに応じて、さまざまな数の302リダイレクトを受け取ることになる：

HTTP/1.1 302 Found
Location: https://eu.api.silentauth.com/phone_check/v0.2/checks/31eaf23d-b2db-4c42-9d1d-e847e75ab330/redirect

リダイレクトをたどると HTTP 200または HTTP 409になります。ネットワークの使用に問題がある場合は、次のようなレスポンスが返ってきます：

HTTP/1.1 409 CONFLICT
Content-Type: application/json

{
  "title": "Network error",
  "detail": "The Silent Auth request could not be completed due to formatting or the carrier is not supported."
}

しかし、すべてがうまくいけば、次のようなペイロードの例で HTTP 200を受け取る：

{
  "request_id": "31eaf23d-b2db-4c42-9d1d-e847e75ab330",
  "code": "si9sfG"
}

ワークフローの最後の部分は、他のベリファイ・チャンネルと同じように codeを送信し、他のVerifyチャンネルと同じようにチェックすることである。

POST https://api.nexmo.com/v2/verify/31eaf23d-b2db-4c42-9d1d-e847e75ab330 HTTP/1.1

Content-Type: application/json
{
  "code": "si9sfG"
}

レスポンスは、SMSなどの他のワークフローで配信されたコードをチェックする場合と同じなので、コードが有効かどうか：

{
   "request_id": "31eaf23d-b2db-4c42-9d1d-e847e75ab330",
   "status": "completed"
}

あるいは、エラーがあった場合：

{
   "title": "Invalid Code",
   "type": "https://www.developer.vonage.com/api-errors/verify#invalid-code",
   "detail": "The code you provided does not match the expected value.",
   "instance": "bf0ca0bf927b3b52e3cb03217e1a1ddf"
}

そうですね。 開発者がしかし、このソリューションの素晴らしさは エンドユーザーにある。正しい携帯電話、有効なキャリア？はい、ログイン完了です！

ご期待ください

サイレント認証は、私たちが今年取り組んでいる一連の製品のスタートを意味します。 開発者プレビューを有効にするために開発者プレビューを有効にするためにサイレント認証の使用を開始したい場合は、私たちに登録することができます。最新情報を知りたいですか？ Twitterデベロッパーアカウントをフォローするまたは 開発者向けドキュメント.