The Nylas platform handles a lot of sensitive information, and it was built from the ground up with security in mind. Nylas implements strict access controls and auditing to make sure we’re doing everything we can to protect sensitive user data and credentials. When you integrate with Nylas, you gain access to some of this sensitive data through access tokens. These tokens grant access to all of your users’ account data via the Nylas APIs. The security of your users’ tokens is crucial for your project.
Nylas does a lot of the work of implementing a secure process for you, especially when you use Hosted Authentication, which prevents you from directly handling and storing either credentials or OAuth tokens for your users’ accounts.
This page lists some recommendations for maintaining a secure environment.
Store secrets securely
Section titled “Store secrets securely”If your project runs in a cloud environment, your infrastructure provider likely provides a secret management service that you should use. Some examples would be…
When you use one of Nylas’ Hosted Authentication methods, you should focus on protecting the following secrets:
- Your Nylas application’s client ID and secret.
- Your Nylas access tokens.
- Your provider auth app’s client ID and secret.
If you’re using Custom Authentication, you need to protect all of the secrets above as well as users’ passwords and OAuth refresh and access tokens.
If you’re not using a secret manager to store these values, you should encrypt them both at rest and in transit. All requests to Nylas must be made over an encrypted TLS connection (HTTPS). We recommend you design your project so you don’t send secrets outside of your own infrastructure. If you need to transmit secrets, be sure to use an encrypted connection.
Many databases have built-in encryption options, so you don’t have to encrypt these secrets on your own. If you do decide to encrypt the secrets in your project’s code, be sure to use a well-known library like libsodium, or a secure library included in your programming language’s standard methods.
We don’t recommend integrating Nylas on the client side of your project, as this gives more opportunities for credentials to be intercepted.
Encrypt stored user data
Section titled “Encrypt stored user data”If your project stores sensitive data from the Nylas API on its servers, you should implement some disk- and/or database-level encryption so all of the data is encrypted at rest. You should also ensure that the data is encrypted whenever it’s in transit. This can usually be done by using TLS connections.
Revoke old access tokens
Section titled “Revoke old access tokens”Nylas’ access tokens don’t expire. When you detect that a user has re-authenticated their grant, you should revoke their unused tokens to minimize the number of active tokens.
We recommend you set up your project to automatically make POST /v3/connect/revoke requests when a user re-authenticates, disconnects, or cancels their account. At any given time, your project should only hold one access token per grant.
More security resources
Section titled “More security resources”The following key management and cryptographic storage cheat sheets provide a good overview of how you can protect your Nylas client secrets and access tokens.
The Key Management Cheat Sheet is an easy to follow, high-level guide on the basics of encryption that explains the concepts required to build a secure application.
We also recommend you double-check any libraries or encryption algorithms you use to make sure they’re actually secure. Cryptographic libraries can have vulnerabilities in their implementations, even if they’re based on secure algorithms. This applies to bindings for different languages as well, because most encryption libraries are implemented in low-level languages like C or C++.
If you’re not sure how to properly secure your data, contact Nylas Support and we’ll help.