The first thing that we do in this application is to call the load_dotenv()
function from the python-dotenv
package. This function will read the contents of the .env file and incorporate all the variables to the environment. Once the environment is populated, we can retrieve our three authentication variables, twilio_account_sid
, twilio_api_key_sid
and twilio_api_key_secret
.
The app
variable is called the “Flask application instance”. Its purpose is to provide the support functions we need to implement our web server using the Flask framework. The @app.route
decorator is used to define a mapping between URLs and Python functions. In this application we are associating the /token URL with the token()
function, so whenever a client sends a POST
request this URL, Flask will run the function and return its response to the client.
The implementation of the token()
function begins by extracting the username and password sent by the client from the request payload, which would allow your application to know which user is making the request.
There are several ways in which the client can submit user credentials, so keep in mind that this is just one of many available options. Another common way to do this is according to the HTTP Basic Authentication specification, via theAuthorization
header.
The application server is now in a position to validate that the user credentials are valid. This needs to be done according to the requirements of your application, by accessing your user database. For this simplified example, validation only checks that both the username
and password
fields were sent by the client and if one or both are missing a 401 status code is returned to tell the client that the user could not be authenticated. In a real application the password has to be checked as well.
Once the user has been validated, an access token can be generated. The AccessToken
class from the Twilio helper library for Python is used for this. The first three arguments to this class are the three secrets that we retrieved from the environment.
The identity
argument sets a unique name for the user, which will be included in the token. If your application does not use unique usernames, then you can use the user IDs stored in the user database.
The final argument is ttl
or “time-to-live”, which specifies for how long the token is going to be valid, in seconds. If ttl
is omitted, the token will be generated with a validity of one hour, or 3600 seconds. You can increase or decrease this time according to your application needs. The maximum value for ttl
is 24 hours, which must be given as 86400 seconds.
The generated token needs to be given grants for the services we are allowing this client to access. In the example above, a grant to a Programmable Video room called “My Room” is added to the token, which means that the client will only be able to access this video room with the token. There are different grant classes for the different Twilio services, as follows:
- VoiceGrant for Programmable Voice
- VideoGrant for Programmable Video
- ConversationsGrant for Conversations
- SyncGrant for Twilio Sync
- ChatGrant for Programmable Chat
Note that a single token can include multiple grants by invoking the add_grant
method as many times as needed.
Once the token has the desired grants it is ready to be returned to the client. The to_jwt()
method renders it as a JSON Web Token to be returned to the client. The token is returned in a JSON payload in the format: