Authentication

Verify API supports two types of authentication:

When should you use Basic Authentication or JWT?

You can use either option, but not both at the same time. In general, we recommend using JWT authentication when working with the Verify API. While Basic authentication is easier for getting started, it does not support the Silent Authentication channel.

Basic Authentication

Basic Authentication sends your API Key and API Secret in the request headers. You can find these credentials in your Dashboard.

Warning: API Key/Secret are sensitive! If you expose them publicly (frontend code, GitHub repos, etc.), anyone can abuse your account.

To create the request header:

  • First, concatenate your API Key and Secret: API_KEY:API_SECRET.
  • Then, Base64 encode the result.
  • Finally, send it in the request as Authorization: Basic BASE64_ENCODED_STRING.

You can do this within your application code - for example, in JavaScript:

JWT

A JWT (JSON Web Token) is an open standard (RFC 7519) for securely transmitting information between parties as a JSON object. The object can optionally be encrypted and signed with a private/public key.

To generate a JWT, you’ll need your application ID and private key, both of which can be found in the Application settings in your Dashboard.

Warning: The generation of all JWTs should be done on the backend. Do not keep tokens’ expiration time longer than required.

There are several ways to generate a new JWT:

vonage auth set --app-id your_application_id --private-key /path/to/your/private.key vonage jwt create

Please note:

  • If you are using one of the Vonage Server SDKs you do not have to generate a JWT separately, as all SDKs support the generation of JWT tokens.

  • If you do not want to generate the JWT using an external tool or library, such as the Vonage SDKs, you can implement your own JWT generation. The how to generate a JWT for network APIs blog post includes examples in JavaScript and Python that show how to generate a JWT without external dependencies.

Once generated, users should be able to use the token to access protected endpoints. This is typically done using the Authorization header using the Bearer schema: