Authentication
Vonage APIs support different authentication methods depending on which product you are using:
| API | API Key and Secret (Query String) | API Key and Secret (Header) | JSON Web Token (JWT) |
|---|---|---|---|
| Accounts | |||
| Application | |||
| Audit | |||
| Conversation | |||
| Conversion | |||
| Device Location Retrieval | |||
| Dispatch | |||
| Identity Insights | |||
| Media | |||
| Messages1 | |||
| Network Features2 | |||
| Numbers | |||
| Number Insight | |||
| Number Insight V2 | |||
| Programmable SIP | |||
| Redact | |||
| Reports | |||
| SMS | |||
| Verify (Legacy) | |||
| Verify3 | |||
| Voice4 | |||
| Video |
1 Messages supports both JWT and Basic authentication, however basic authentication does not support webhooks or advanced features such as ACLs. For most use-cases we recommend JWT Authentication. See Messages API Authentication
2 The JWT token generated serves as a bridge for generating a CAMARA access token, needed to access the Network Features. The workflow varies based on whether the authentication is initiated from the frontend or the backend. Visit the Network Feature authentication guide to learn more.
3 Verify supports both JWT and Basic authentication, however basic authentication does not support webhooks or advanced features such as ACLs.
4 SIP Trunking uses Digest Authentication method with the API Key as user and API Secret as password.
Contents
In this document you can learn about authentication via the following means:
API Key and Secret
When you create a Vonage account, an API key and secret will be created for you. These are located in your account settings in the Vonage Dashboard. You should always keep these secure and never share these details: be careful when adding it to your codebase to make sure they are not shared with anyone who may use it maliciously. If you use message signatures, these are generated using the SIGNATURE_SECRET rather than the API_SECRET; both values can be found in your account settings.
Note: The secret should always be kept secure and never shared. Be careful when adding it to your codebase to make sure it is not shared with anyone who may use it maliciously. Read more about the Best Security Practices for your Vonage Account.
Vonage APIs may require your API Key and Secret in a number of different ways.
Request Body
For POST requests to the SMS API, your API key and secret should be sent as part of the body of the request in the JSON object.
Query String
Your API key and secret should be included in the query parameters of requests you make to the Conversion, Number Insight or Developer API. The parameters are called API_KEY and API_SECRET respectively.
An example of authentication query parameters would be as follows:
?api_key=VONAGE_API_KEY&api_secret=VONAGE_API_SECRET The request may also need other query parameters and these can be added in any order.
Basic Authentication
A number of newer Vonage APIs require authentication to be done using an API key and secret sent Base64 encoded in the Authorization header.
For these APIs, you send your API key and secret in the following way:
Authorization: Basic base64(API_KEY:API_SECRET) If your API key were aaa012 and your API secret were abc123456789, you would concatenate the key and secret with a : (colon) symbol and then encode them using Base64 encoding to produce a value like this:
Authorization: Basic YWFhMDEyOmFiYzEyMzQ1Njc4OQ== A website for generating Base64 encoded strings can be found here:
- General: Base64 Encode and Decode
Details on how to encode Base64 strings in a variety of programming languages can be found at the following websites:
- C#/.NET: How do I encode and decode a Base64 string? from StackOverflow
- Go: Base64 Encoding from Go By Example
- Java: Base64
- JavaScript: Base64 encoding and decoding from MDN web docs
- PHP: base64_encode
- Python: Base64
- Ruby: Base64
- Swift: Base64 Encode and Decode in Swift from iOS Developer Tips
Secret Rotation
It is possible to have two API secrets to be used against one API key at the same time. This way you can create a second API secret and test it before revoking the existing API secret in your production network. The API secret rotation procedure consists of the following steps:
- Create a second API secret in your account settings or by using the secret rotation API.
- Update one or more of your servers to use the newly created API secret for making calls to Vonage APIs
- Test that there are no connectivity issues and roll out the API secret update across the remaining servers
- Delete the replaced API secret
JSON Web Tokens
JSON Web Tokens (JWTs) are a compact, URL-safe means of representing claims to be transferred between two parties. For a full list of the APIs that use JWTs, please see the table above.
Header and Payload
JWTs consist of a Header and a Payload. The values for the Header are:
| Name | Description | Required |
|---|---|---|
alg | The encryption algorithm used to generate the JWT. RS256 is supported. | |
typ | The token structure. Set to JWT. |
The values for the payload claim are:
| Name | Description | Required |
|---|---|---|
application_id | The unique ID allocated to your application by Vonage. | |
iat | The UNIX timestamp at UTC + 0 indicating the moment the JWT was requested. | |
jti | A unique string identifier of the JWT. | |
nbf | The UNIX timestamp at UTC + 0 indicating the moment the JWT became valid. | |
exp | The UNIX timestamp at UTC + 0 indicating the moment the JWT is no longer valid. A minimum value of 30 seconds from the time the JWT is generated. A maximum value of 24 hours from the time the JWT is generated. A default value of 15 minutes from the time the JWT is generated. |
Generating JWTs
Using the Vonage API online tool to generate a JWT
You can generate a JWT using our online tool.
Using the Vonage CLI to generate JWTs
The Vonage CLI provides a command for generating a JWT.
An example of generating a JWT for an application is as follows:
# A command with parameters vonage jwt create ` --app-id='00000000-0000-0000-0000-000000000000' ` --private-key=./private.key # Will produce a token eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9.eyJleHAiOjE3MzYyODE5NDYsImp0aSI6IjBmZjcwZDNmLTAzN2EtNGY4MC04ODZjLWI3MmM3MmQyMWNmMiIsImlhdCI6MTczNjI4MTA0NiwiYXBwbGljYXRpb25faWQiOiIwMDAwMDAwMC0wMDAwLTAwMDAtMDAwMC0wMDAwMDAwMDAwMDAifQ.gA7jClpqaZ2OoS0iri-zGCbda4jO7C0M8mka0EnSyjlds1EeY8fNoBEx3FTXHfkkzzrj0TskrWc_dcs1wuM8Kx55c5rLQ7taVpDAYopKSc_CeeOaad8S6aWnRkTUTNeduO4aIn-0CbyRTluBYsH1RBqYBQvobuQIDEwbFw8xBgx0UfREMMN6DAWknR57eiVXN9x_oD6CGQJ1yV3025nGboeMsP9YgX4Nwc-rE2r8c1ZGwCLO81x8i19Qil3Nwu5q1nzouyavQjIw00B_TZkushnI1ufdi_GNqk-h5q2HvGkg7Pj9bVkZHFdVTO8im03JYNyJmcV83vnpjOLuCFRzxQ REM A command with parameters vonage jwt create ^ --app-id='00000000-0000-0000-0000-000000000000' ^ --private-key=./private.key REM Will produce a token eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9.eyJleHAiOjE3MzYyODE5NDYsImp0aSI6IjBmZjcwZDNmLTAzN2EtNGY4MC04ODZjLWI3MmM3MmQyMWNmMiIsImlhdCI6MTczNjI4MTA0NiwiYXBwbGljYXRpb25faWQiOiIwMDAwMDAwMC0wMDAwLTAwMDAtMDAwMC0wMDAwMDAwMDAwMDAifQ.gA7jClpqaZ2OoS0iri-zGCbda4jO7C0M8mka0EnSyjlds1EeY8fNoBEx3FTXHfkkzzrj0TskrWc_dcs1wuM8Kx55c5rLQ7taVpDAYopKSc_CeeOaad8S6aWnRkTUTNeduO4aIn-0CbyRTluBYsH1RBqYBQvobuQIDEwbFw8xBgx0UfREMMN6DAWknR57eiVXN9x_oD6CGQJ1yV3025nGboeMsP9YgX4Nwc-rE2r8c1ZGwCLO81x8i19Qil3Nwu5q1nzouyavQjIw00B_TZkushnI1ufdi_GNqk-h5q2HvGkg7Pj9bVkZHFdVTO8im03JYNyJmcV83vnpjOLuCFRzxQ The private key in question is generated from the application dashboard or from vonage apps create. You can save this information for the CLI by running vonage auth set. The contents of the private key will then be saved in either the .vonagerc file or $HOME/.vonage/config.json.
Further information on the Vonage CLI can be found in its repository on GitHub.
Examples of using the Vonage libraries to generate JWTs can be found below. If you are not using a Vonage library you should refer to RFC 7519 to implement JWTs.
Vonage Client SDKs
The Vonage Client and Video SDKs use JWTs for authentication when a client connects to Vonage. These JWTs are generated using the application ID and private key that is provided when a new application is created.
Claims
Using that private.key and the application ID, you can mint a new JWT. In order to log a user into a Vonage client, the JWT will need the following claims:
Vonage Client SDK
| Claim | Description |
|---|---|
sub | The "subject". The subject, in this case, will be the name of the user created and associated with your Vonage Application. |
acl | Access control list. The Client SDK uses this as a permission system for users. Read more about it in the ACL overview. |
application_id | This is the ID of the Vonage Application you created. |
iat | "Issued at time" This is the time the JWT was issued, in unix epoch time. |
jti | "JWT ID". This is a unique string identifier for this JWT. |
exp | "Expiration time" This is the time in the future that the JWT will expire, in unix epoch time. |
The exp claim is optional. If the claim is not provided, then the JWT will expire by default in 15 minutes. The max expiration time for a JWT is 24 hours. JWTs should typically be short-lived, as it is trivial to create a new JWT and some JWTs can have multiple far-reaching permissions.
Sample Client SDK JWT Payload
Once all the claims have been provided, the resulting claims should appear like so:
{ "iat": 1532093588, "jti": "705b6f50-8c21-11e8-9bcb-595326422d60", "sub": "alice", "exp": "1532179987", "acl": { "paths": { ... } }, "application_id": "aaaaaaaa-bbbb-cccc-dddd-0123456789ab" } ( ... snippet is truncated)
Vonage Video Client SDK
| Claim | Description |
|---|---|
sub | The "subject". The subject, in this case, should be the string video. |
acl | Access control list. The Client SDK uses this as a permission system for users. Read more about it in the ACL overview. |
application_id | This is the ID of the Vonage Application you created. |
session_id | This is the ID of the Session you created. |
scope | This is the scope of the token. It should be the string session.connect. |
role | This is the role of the token. It can be a range of string values depending on what permissions you want to grant this token. |
data | This custom metadata you can optionally add to describe the token. This is a string limited to 1000 characters. |
initial_layout_class_list | This lets you optionally, when broadcasting, specify the initial layout class list for streams published by the client. |
iat | "Issued at time" This is the time the JWT was issued, in unix epoch time. |
jti | "JWT ID". This is a unique string identifier for this JWT. |
exp | "Expiration time" This is the time in the future that the JWT will expire, in unix epoch time. |
The exp claim is optional. If the claim is not provided, then the JWT will expire by default in 24 hours. The max expiration time for a Video SDK JWT is 30 days. JWTs should typically be short-lived, as it is trivial to create a new JWT and some JWTs can have multiple far-reaching permissions. Always make sure to try and set an exp time to the least amount of time that is feasible for your application.
Sample Video Client SDK JWT Payload
{ "scope": "session.connect", "session_id": "1_MX44YjY4NTFmZS01NjdjLTRlODYtYWRmOC0zYmVhODM2MzNjNjB-fjE3NDIzMDY0ODY0NjZ-WS9FOHhybUdHV0JtTGZYTEV2aVlwV1N4fn5-", "role": "moderator", "initial_layout_class_list": "", "sub": "video", "acl": { "paths": { "/session/**": {} } }, "jti": "c04c96ba-3229-4fd4-9f55-406b6a6eb485", "iat": 1742306486, "exp": 1742307386, "application_id": "8b6851fe-567c-4e86-adf8-3bea83633c60" } Access Control List (ACL)
In the sample JWT request payload above, notice how the acl claim has a paths object. The path object contains a list of endpoints that correspond to certain permissions a user has when using the Client SDK.
Below is the list of endpoints you can grant a user access to:
| Endpoint | Description | Required for |
|---|---|---|
/*/rtc/** | Create signalling session to receive events and send metrics | In-app calls/message |
/*/sessions/** | Log in as an in-app voice or chat user | In-app calls/messages |
/*/users/** | Getting user conversations, user sessions and user object | In-app calls/messages |
/*/conversations/** | Create and manage conversations & send/receive messages | In-app calls/messages |
/*/knocking/** | Start phone calls | In-app calls |
/*/devices/** | Register device to receive push notifications | In-app calls/messages |
/*/legs/** | Create and manage legs in a conversation | In-app calls |
/*/session/** | Connect to a video session | Video |
You should provide the user you are generating with permissions to access only the relevant paths. For instance, if the Voice Client SDK user is not going to need to fetch information about their User object or other Users, you should omit the users path. To further illustrate, if you add the /*/conversations/** path to a JWT's ACL, the user will be able to create and manage conversations. Also, if this is the only ACL set, the user will only have access to the /conversations endpoint.
Note: Using wildcards in your ACL paths (e.g. /*/conversations/**) will allow the JWT token to access all the operations for that endpoint. It is strongly recommended that you use more granular control of your ACL paths as illustrated below.
Granular ACL Paths
Above, we looked at how to grant users access to endpoints. You may also limit or grant access based on sub-paths and HTTP methods. This allows you to very granularly define what permissions a token should have. For example in your Voice Client SDK application you want users to be able to get information about a conversation:
{ "acl": { "paths": { "/*/conversations/**": {} } } } The above ACL paths allows anyone with this token to make requests to any Conversation API endpoint linked to your Vonage application. This will allow whoever holds this token get a list of ongoing Conversations in your application, create new Conversations, or more. To mitigate this, you can specify which paths specifically should be accessible and which HTTP methods are allowed to be used on those paths.
{ "acl": { "paths": { "/*/conversations/*": { "methods": [ "GET" ] } } } } This new ACL paths allows anyone with this token to only make a GET request to a specific conversation and no further subpaths or operations. Which is far more restrictive than before.
Minimum ACL Paths for Client SDKs
Below are the minimum ACL paths needed to perform various actions in the Vonage Client SDKs. To add support for more endpoints based on your use case, refer to the ACL table above and add them as restrictively as possible.
This supports the basic use case of creating a session, using serverCall, reconnectCall, and being able to answer, reject, hangup a call.
{ "acl": { "paths": { "/*/sessions/**": { "methods": ["POST"] }, "/*/conversations/*": { "methods": ["GET"] }, "/*/conversations/*/rtc/*/answer": { "methods": ["POST"] }, "/*/conversations/*/rtc/*/offer/*": { "methods": ["POST"]}, "/*/conversations/*/members/*": { "methods": ["PUT", "DELETE"] }, "/*/knocking/**": { "methods": ["POST", "DELETE"] }, "/*/legs/**": { "methods": ["POST", "GET"] }, "/*/v2/rtc/**": { "methods": ["POST", "GET"] } } } } In addition to the base Calling case, this will allow you to use SDK functions such as mute, say, etc. This is needed for the Chat SDK.
{ "acl": { "paths": { "/*/sessions/**": { "methods": ["POST"] }, "/*/conversations/*": { "methods": ["GET"] }, "/*/conversations/*/events/*": { "methods": ["POST", "GET"]}, "/*/conversations/*/rtc/*/answer": { "methods": ["POST"] }, "/*/conversations/*/rtc/*/offer/*": { "methods": ["POST"]}, "/*/conversations/*/members/*": { "methods": ["PUT", "DELETE"] }, "/*/knocking/**": { "methods": ["POST", "DELETE"] }, "/*/legs/**": { "methods": ["POST", "GET"] }, "/*/v2/rtc/**": { "methods": ["POST", "GET"] } } } } In addition to the base Calling case, this will allow you to use SDK functions to manage push tokens. Add the device methods you want to support as needed.
{ "acl": { "paths": { "/*/sessions/**": { "methods": ["POST"] }, "/*/conversations/*": { "methods": ["GET"] }, "/*/conversations/*/rtc/*/answer": { "methods": ["POST"] }, "/*/conversations/*/rtc/*/offer/*": { "methods": ["POST"]}, "/*/conversations/*/members/*": { "methods": ["PUT", "DELETE"] }, "/*/knocking/**": { "methods": ["POST", "DELETE"] }, "/*/legs/**": { "methods": ["POST", "GET"] }, "/*/v2/rtc/**": { "methods": ["POST", "GET"] }, "/*/devices/**": { "methods": [] } } } } Devices methods:
- POST - Register new user devices.
- GET - Fetch registered devices for the user.
- PUT - Update registered devices for the user.
- DELETE - Delete registered devices for the user.
In addition to the base Calling case, this will allow you to use SDK functions to get information about a specific user.
{ "acl": { "paths": { "/*/sessions/**": { "methods": ["POST"] }, "/*/conversations/*": { "methods": ["GET"] }, "/*/conversations/*/rtc/*/answer": { "methods": ["POST"] }, "/*/conversations/*/rtc/*/offer/*": { "methods": ["POST"]}, "/*/conversations/*/members/*": { "methods": ["PUT", "DELETE"] }, "/*/knocking/**": { "methods": ["POST", "DELETE"] }, "/*/legs/**": { "methods": ["POST", "GET"] }, "/*/v2/rtc/**": { "methods": ["POST", "GET"] }, "/*/users/*": { "methods": ["GET"] }, } } } This supports connecting to a session with the Video SDK
{ "acl": { "paths": { "/*/session/**": {} } } } Generating JWTs using the Vonage CLI
The Server SDKs contain methods for generating JWT tokens. You may however use the Vonage CLI to do this as well. This is particularly helpful during testing.
# A command with parameters vonage jwt create ` --app-id='00000000-0000-0000-0000-000000000000' ` --private-key=./private.key ` --sub='Alice' ` --acl='{\"paths\":{\"\/*\/users\/**\":{},\"\/*\/conversations\/**\":{},\"\/*\/sessions\/**\":{},\"\/*\/devices\/**\":{},\"\/*\/push\/**\":{},\"\/*\/knocking\/**\":{},\"\/*\/legs\/**\":{}}}' # Will produce a token eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9.eyJhY2wiOnsicGF0aHMiOnsiLyovcnRjLyoqIjp7fSwiLyovdXNlcnMvKioiOnt9LCIvKi9jb252ZXJzYXRpb25zLyoqIjp7fSwiLyovc2Vzc2lvbnMvKioiOnt9LCIvKi9kZXZpY2VzLyoqIjp7fSwiLyovcHVzaC8qKiI6e30sIi8qL2tub2NraW5nLyoqIjp7fSwiLyovbGVncy8qKiI6e319fSwiZXhwIjoxNzQxMTgyMzA3LCJzdWIiOiJBbGljZSIsImp0aSI6Ijg1MTViNzk2LTA1YjktNGFkMS04MTRkLTE1NWZjZTQzZWM1YiIsImlhdCI6MTc0MTE4MTQwNywiYXBwbGljYXRpb25faWQiOiIwMDAwMDAwMC0wMDAwLTAwMDAtMDAwMC0wMDAwMDAwMDAwMDAifQ.BscMdDXZ1-nuLtKyPJvw9tE8E8ZjJvTPJPMT9y0TjPz4Q7qqNaqxcjglc5QPtYEjh2YpZH6btSKbUF4XTClI026Hl5_QOBlnayYo7jXwhba16fa5PeyzSf30QFGFrHbANwrQJFVCjd329SZUpwK4GxgB1gf230NhbfmkhegKezqicru2WTGCKm8kQncYliFwIEYUlcRAb2c8xcaVrn_6QNNahyeJRwGFfWpIkX0Oe-S4RDlPjoq47_gYWac9MmaetB4Dd3Yp531AuniGV5JiIShkaEwuY4Zyov4Hcmajm4Lm_UFY119la7vzHis0P7cT9pPUDe5cyPj7eT8-VhitfQ REM A command with parameters vonage jwt create ^ --app-id='00000000-0000-0000-0000-000000000000' ^ --private-key=./private.key ^ --sub='Alice' ^ --acl="{\"paths\":{\"\/*\/users\/**\":{},\"\/*\/conversations\/**\":{},\"\/*\/sessions\/**\":{},\"\/*\/devices\/**\":{},\"\/*\/push\/**\":{},\"\/*\/knocking\/**\":{},\"\/*\/legs\/**\":{}}}" REM Will produce a token eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9.eyJhY2wiOnsicGF0aHMiOnsiLyovcnRjLyoqIjp7fSwiLyovdXNlcnMvKioiOnt9LCIvKi9jb252ZXJzYXRpb25zLyoqIjp7fSwiLyovc2Vzc2lvbnMvKioiOnt9LCIvKi9kZXZpY2VzLyoqIjp7fSwiLyovcHVzaC8qKiI6e30sIi8qL2tub2NraW5nLyoqIjp7fSwiLyovbGVncy8qKiI6e319fSwiZXhwIjoxNzQxMTgyMzA3LCJzdWIiOiJBbGljZSIsImp0aSI6Ijg1MTViNzk2LTA1YjktNGFkMS04MTRkLTE1NWZjZTQzZWM1YiIsImlhdCI6MTc0MTE4MTQwNywiYXBwbGljYXRpb25faWQiOiIwMDAwMDAwMC0wMDAwLTAwMDAtMDAwMC0wMDAwMDAwMDAwMDAifQ.BscMdDXZ1-nuLtKyPJvw9tE8E8ZjJvTPJPMT9y0TjPz4Q7qqNaqxcjglc5QPtYEjh2YpZH6btSKbUF4XTClI026Hl5_QOBlnayYo7jXwhba16fa5PeyzSf30QFGFrHbANwrQJFVCjd329SZUpwK4GxgB1gf230NhbfmkhegKezqicru2WTGCKm8kQncYliFwIEYUlcRAb2c8xcaVrn_6QNNahyeJRwGFfWpIkX0Oe-S4RDlPjoq47_gYWac9MmaetB4Dd3Yp531AuniGV5JiIShkaEwuY4Zyov4Hcmajm4Lm_UFY119la7vzHis0P7cT9pPUDe5cyPj7eT8-VhitfQ Using the Server SDKs
It is expected that the accompanying server for your Vonage application will generate JWTs for the Client SDKs. Here are some examples using the Vonage Server SDKs:
Version 3 of the Vonage Node Server SDK includes a package for generating JWT tokens. It can also generate a JWT using the appropriate claims.
const { tokenGenerate } = require('@vonage/jwt'); const privateKey = readFileSync('path/to/private.key'); const aclPaths = { "paths": { ... } } const token = tokenGenerate("aaaaaaaa-bbbb-cccc-dddd-0123456789ab", privateKey, { //expire in 24 hours exp: Math.round(new Date().getTime()/1000)+86400, sub: "Alice", acl: aclPaths, }); The Vonage JWT JDK library can be used to generate a signed JWT with claims.
val token : String = Jwt.builder() .applicationId("aaaaaaaa-bbbb-cccc-dddd-0123456789ab") .privateKeyPath("/path/to/private.key") .issuedAt(ZonedDateTime.now()) .subject("Alice") .addClaim("acl", mapOf( "paths" to mapOf( ... ) )) .build() .generate() The Vonage JWT JDK library can be used to generate a signed JWT with claims.
String token = Jwt.builder() .applicationId("aaaaaaaa-bbbb-cccc-dddd-0123456789ab") .privateKeyPath(Paths.get("/path/to/private.key")) .subject("Alice") .issuedAt(ZonedDateTime.now()) .expiresAt(ZonedDateTime.now().plusMinutes(20)) .addClaim("acl", Map.of( "paths", Map.of( ... ) )) .build() .generate(); The Vonage .NET SDK can be used to generate a signed JWT with claims.
As an example, let's assume we want to add the following claims in the JWT:
var payload = new Dictionary<string, object> { {"sub", "Alice"}, {"exp", DateTimeOffset.UtcNow.AddDays(1).ToUnixTimeSeconds().ToString()}, { "acl", new Dictionary<string, object> { ["paths"] = new Dictionary<string, object> { ... }, } }, }; There are several ways to generate a JWT.
You can either use the static method CreateToken on the Jwt class:
var credentials = Credentials.FromAppIdAndPrivateKeyPath(VONAGE_APPLICATION_ID, VONAGE_APPLICATION_PRIVATE_KEY_PATH); var token = Jwt.CreateToken(credentials.ApplicationId, credentials.ApplicationKey, payload); Or use the method GenerateToken on a Jwt instance:
// Using the credentials instance var result = tokenGenerator.GenerateToken(credentials, payload); // Using ApplicationId and ApplicationKey values var result = tokenGenerator.GenerateToken(credentials.ApplicationId, credentials.ApplicationKey, payload); The current version of the Vonage PHP Server SDK can also create a JWT including the appropriate claims when using the Keypair authentication.
$keypair = new \Vonage\Client\Credentials\Keypair( file_get_contents('/path/to/private.key'), 'aaaaaaaa-bbbb-cccc-dddd-0123456789ab' ); $client = new \Vonage\Client($keypair); $claims = [ 'acl' => [ 'paths' => [ ... ] ] ]; $token = $client->generateJwt($claims); $tokenString = $token->toString(); The Vonage Python JWT library can be used to generate a signed JWT with default or custom claims.
from vonage_jwt import JwtClient jwt_client = JwtClient(application_id, private_key) # The `claims` field is optional and can be omitted as defaults are set paths = { ... } claims = {'sub': 'Alice', 'paths': paths} vonage_jwt = jwt_client.generate_application_jwt(claims) The Vonage JWT JDK library can be used to generate a signed JWT with claims.
@builder = Vonage::JWTBuilder.new(application_id: YOUR_APPLICATION_ID, private_key: YOUR_PRIVATE_KEY) @token = @builder.jwt.generate ( ... snippet is truncated)