Authentication
Ably clients can authenticate with Ably in one of two ways. They can use Basic Authentication or Token Authentication. Basic Authentication makes use of the customer’s API key to connect with Ably. Token Authentication requires a server to provide an Ably Token, an Ably TokenRequest, an Ably JWT (JSON Web Token), or an External JWT with an embedded Ably-compatible token to the client. Token Authentication, in most cases, is the recommended strategy due to it providing robust access control and stringent security measures.
Understanding the Ably authentication schemes
This page of documentation is intended to describe the Realtime Authentication API and is not intended to explain in depth how Ably’s authentication works. If you are new to Ably and/or the authentication schemes, we strongly recommend that you get acquainted with the following first:
- Getting started with Ably’s authentication
- Selecting the right authentication scheme
- Basic Authentication explained
- Token Authentication explained
Tutorials
If you’re the kind of person who prefers to dive into code, we have client-server authentication tutorials.
Basic Authentication
Basic Authentication uses one of the api keys configured via the application dashboard as the authentication token. Basic Authentication is the simplest method to use but has some important limitations described in detail in the Basic Authentication documentation.
Here is a straightforward example of using Basic Authentication to connect to Ably:
var realtime = new Ably.Realtime({ key: '<loading API key, please wait>' });
Demo OnlyCopyCopied!Token Authentication
Token Authentication uses an Ably-compatible token to authenticate with Ably. This can be an Ably Token obtained via the REST API requestToken endpoint, an Ably JWT signed by your API key, or an External JWT object with an embedded Ably-compatible token.
Tokens are authentication credentials that are short-lived, and therefore they may more readily be distributed to clients where there is a risk of compromise. Tokens may also be issued with a particular scope – such as a limited set of access rights or capabilities or being limited to use by a specific clientId identity – and therefore token-based authentication provides the flexibility to implement access and identity control policies in the application. See the Token Authentication documentation for more details. To initialize the Realtime library to a previously obtained Ably Token or Ably JWT, set the token or tokenDetails attribute of ClientOptions to the token.
Token refresh using authUrl
Below is an example that instances a Realtime library using Token Authentication with a means to reissue tokens as required.
Typically, in a browser environment, the authUrl provided would be a URL relative to an endpoint under the same origin. This endpoint issues tokens to trusted clients. Client requests can, for example, be trusted based on session cookies.
const realtime = new Ably.Realtime({ authUrl: '/auth' });
CopyCopied!How to specify auth options
Auth options uses properties set with AuthOptions to override the default authentication values set when instantiating the client library. You can also embed AuthOptions into your ClientOptions while instantiating the client library.
There are several auth options you can specify along with authUrl and authCallback:
authMethod– whenauthUrlis called, the default “GET“ method will be used, unless “POST“ is specified.authHeaders– allows you to pass additional headers as required, depending on your use case.authParams– allows you to pass additional query parameters, depending on your use case.
const realtime = new Ably.Realtime({ authUrl: "/auth", authMethod: "POST", authParams: { p1: param1, b: param2}, authHeaders: {h1: header1, h2: header2} });
CopyCopied!Token refresh using authCallback
For non-browser clients, an authentication callback is the preferred method of implementing token refresh, although browser clients can also use authCallback if the use case requires it. This relies on your application communicating securely with your own servers to obtain a token.
The following code sample shows an example of using an authCallback in a client:
const realtime = new Ably.Realtime({
authCallback: (tokenParams, callback) => {
// implement your callback here
},
});
CopyCopied!Selecting an authentication mechanism
When deciding on which authentication method you will be using, it is recommended to bear in mind the principle of least privilege a client should ideally only possess the credentials and rights that it needs to accomplish what it wants; this way, if the credentials are compromised, the rights that can be abused by an attacker are minimized.
The table below should be used as a rough guide as to what you should consider when choosing your authentication method. Many applications will most naturally use a mixed strategy: one or more trusted application servers will use basic authentication to access the service and issue tokens over HTTPS, whereas remote browsers and devices will use individually issued tokens:
| Scenario | Basic | Token | Description |
|---|---|---|---|
| Your scripts may be exposed | No | Yes | If the script, program or system holding the key is exposed, for example on a user’s device, you should not embed an API key and instead use Token Authentication. If the script is on a secure environment such as your own server, an API key with Basic Authentication is fine. |
| Your connection may be insecure | No | Yes | If there is a risk of exposure of the client’s credentials, either directly or over an insecure, or insecurely proxied, connection, Token Authentication should be used. If you are sure the connection is secure and unmediated, Basic Authentication is acceptable. |
| You have no server to control access | Yes | No | If you do not have your own server to perform authentication and provide tokens to users, you’ll need to use Basic Authentication. |
| You require fine-grained access control | No | Yes | If you need to provide privileges on a user-by-user basis, you’d be better using Token Authentication. If you only need a few access control groups, Basic Authentication is reasonable. |
| Users need restricted periods of access | No | Yes | If you need users to only have access for a certain period of time, or the ability to revoke access, Token Authentication is needed. If users are able to always have access, Basic Authentication is acceptable. |
| Users need to identify themselves | Partial | Yes | If the user can be trusted to identify itself, Basic Authentication is fine. If the user cannot be trusted however, Token Authentication is better as it allows for a trusted token distributor to identify the user instead. |
Identified clients
When a client is authenticated and connected to Ably, they are considered to be an authenticated client. However, whilst an authenticated client has a verifiable means to authenticate with Ably, they do not necessarily have an identity. When a client is assigned a trusted identity (i.e. a clientId), then they are considered to be an identified client and for all operations they perform with the Ably service, their clientId field will be automatically populated and can be trusted by other clients.
We encourage customers to always issue tokens to clients so that they authenticate using the short-lived token and do not have access to a customer’s private API keys. Since the customer can then control the clientId that may be used by any of its clients, all other clients can rely on the validity of the clientId in published messages and of members present in presence channels.
The following example demonstrates how to issue an Ably TokenRequest with an explicit clientId that, when used by a client, will then be considered an identified client.
var realtime = new Ably.Realtime({ key: '<loading API key, please wait>' });
realtime.auth.createTokenRequest({ clientId: 'Bob' }, function(err, tokenRequest) {
/* ... issue the TokenRequest to a client ... */
})
Demo OnlyCopyCopied!API Reference
View the Authentication API Reference.