Authentication
Ably clients can authenticate with Ably using Basic Authentication (which uses the customer’s API key), Token Authentication (which relies on a token customers obtain from Ably), or a token request that customers sign and issue to their clients. Token Authentication, in most cases, is the recommended strategy as it provides 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
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: 'xVLyHw.0cALlg:derlO51V-Q8OvabUr8zAakOPSm3g-3d8wALqx_EqBYI' });
var realtime = new Ably.Realtime({ key: 'xVLyHw.0cALlg:derlO51V-Q8OvabUr8zAakOPSm3g-3d8wALqx_EqBYI' });
realtime = Ably::Realtime.new(key: 'xVLyHw.0cALlg:derlO51V-Q8OvabUr8zAakOPSm3g-3d8wALqx_EqBYI')
ClientOptions options = new ClientOptions();
options.key = "xVLyHw.0cALlg:derlO51V-Q8OvabUr8zAakOPSm3g-3d8wALqx_EqBYI";
AblyRealtime realtime = new AblyRealtime(options);
let realtime = ARTRealtime(key: "xVLyHw.0cALlg:derlO51V-Q8OvabUr8zAakOPSm3g-3d8wALqx_EqBYI")
ARTRealtime *realtime = [[ARTRealtime alloc] initWithKey:@"xVLyHw.0cALlg:derlO51V-Q8OvabUr8zAakOPSm3g-3d8wALqx_EqBYI"];
AblyRealtime realtime = AblyRealtime("xVLyHw.0cALlg:derlO51V-Q8OvabUr8zAakOPSm3g-3d8wALqx_EqBYI");
Token Authentication
Token Authentication uses a token obtained via the REST API requestToken
RequestToken
endpoint to authenticate with Ably. 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
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.
The Realtime library will typically be instantiated with a means to obtain a token as opposed to a short-lived token so that when the token expires, the library can assume responsibility to automatically obtain a new token and seamlessly continue operations with Ably. Conversely, if a library is instantiated with a previously obtained Token
by setting the :token
or :token_details
token
or token_details
Token
or TokenDetails
token
or tokenDetails
attributes of ClientOptions
, when the token expires, the client will be disconnected and enter the FAILED
state as the library has no means to obtain a new token. It is therefore recommended that all client libraries that use token authentication have a means to issue new tokens using either the auth_url
or auth_callback
AuthUrl
or AuthCallback
authUrl
or authCallback
attribute of ClientOptions
when instancing the library.
Below is a rather contrived yet straightforward example that instances a Realtime library using Token Authentication with a means to reissue tokens as required. Typically, in a browser environment, the authUrl
AuthUrl
provided would be a relative URL to a local endpoint that is used to issue tokens to trusted clients. Client requests can, for example, be trusted based on session cookies. For non-browser clients, an authentication callback is preferred thus relying on your application to communicate securely with your own servers to obtain a token.
var realtime = new Ably.Realtime({ authUrl: 'http://my.website/auth' });
var realtime = new Ably.Realtime({ authUrl: 'http://my.website/auth' });
realtime = Ably::Realtime.new(auth_url: 'http://my.website/auth')
ClientOptions options = new ClientOptions();
options.authUrl = "http://my.website/auth";
AblyRealtime realtime = new AblyRealtime(options);
ARTClientOptions *options = [[ARTClientOptions alloc] init];
options.authUrl = [NSURL URLWithString:@"http://my.website/auth"];
ARTRealtime *realtime = [[ARTRealtime alloc] initWithOptions:options];
let options = ARTClientOptions()
options.authUrl = NSURL(string: "http://my.website/auth")
let realtime = ARTRealtime(options: options)
ClientOptions options = new ClientOptions();
options.AuthUrl = new Uri("http://my.website/auth");
AblyRealtime realtime = new AblyRealtime(options);
Auth object
The principal use-case for Auth
object is to create signed token request objects or obtain tokens from Ably, and then issue them to other “less trusted” clients. Typically, your servers should be the only devices to have a private API key, and this private API key is used to securely sign token requests or request tokens from Ably. Clients are then issued with short-lived tokens or token requests, and the libraries can then use these to authenticate with Ably. If you adopt this model, your private API key is never shared with clients directly.
A subsidiary use-case for the Auth
object is to preemptively trigger renewal of a token or to acquire a new token with a revised set of capabilities by explicitly calling authorize
Authorize
.
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 client_id
ClientId
clientId
), then they are considered to be an identified client and for all operations they perform with the Ably service, their client_id
ClientId
clientId
field will be automatically populated and can be trusted by other clients.
For example, assuming you were building a chat application and wanted to allow clients to publish messages and be present on a channel. If each client is assigned a trusted identity by your server, such as a unique email address or UUID, then all other subscribed clients can trust any messages or presence events they receive in the channel as being from that client. No other clients are permitted to assume a client_id
ClientId
clientId
that they are not assigned in their token or token request, that is they are unable to masquerade as another client_id
ClientId
clientId
.
In Ably a client can be identified with a client_id
ClientId
clientId
in three ways:
- if the client is authenticated with a token that is issued for that
client_id
ClientId
clientId
. Seerequest_token
requestToken
andcreate_token_request
createTokenRequest
documentation below; - if the client claims that
client_id
ClientId
clientId
and is authenticated using Basic Authentication (using an API key); - if the client claims that
client_id
ClientId
clientId
and is authenticated with a token that is issued for a wildcardclient_id
wildcardClientId
wildcardclientId
(a special token privilege that allows any client identity to be assumed)
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 client_id
ClientId
clientId
that may be used by any of its clients, all other clients can rely on the validity of the client_id
ClientId
clientId
in published messages and of members present in presence channels.
The following example demonstrates how to issue a token with an explicit client_id
ClientId
clientId
that, when used by a client, will then be considered an identified client.
var realtime = new Ably.Realtime({ key: 'xVLyHw.0cALlg:derlO51V-Q8OvabUr8zAakOPSm3g-3d8wALqx_EqBYI' });
realtime.auth.createTokenRequest({ clientId: 'Bob' }, function(err, tokenRequest) {
/* ... issue the TokenRequest to a client ... */
})
var realtime = new Ably.Realtime({ key: 'xVLyHw.0cALlg:derlO51V-Q8OvabUr8zAakOPSm3g-3d8wALqx_EqBYI' });
realtime.auth.createTokenRequest({ clientId: 'Bob' }, function(err, tokenRequest) {
/* ... issue the TokenRequest to a client ... */
})
realtime = Ably::Realtime.new(key: 'xVLyHw.0cALlg:derlO51V-Q8OvabUr8zAakOPSm3g-3d8wALqx_EqBYI')
realtime.auth.createTokenRequest(client_id: 'Bob') do |token_request|
# ... issue the TokenRequest to a client ...
end
ClientOptions options = new ClientOptions();
options.key = "xVLyHw.0cALlg:derlO51V-Q8OvabUr8zAakOPSm3g-3d8wALqx_EqBYI";
AblyRealtime realtime = new AblyRealtime(options);
TokenParams tokenParams = new TokenParams();
tokenParams.clientId = "Bob";
TokenRequest tokenRequest;
tokenRequest = realtime.auth.createTokenRequest(tokenParams, null);
/* ... issue the TokenRequest to a client ... */
AblyRealtime realtime = new AblyRealtime("xVLyHw.0cALlg:derlO51V-Q8OvabUr8zAakOPSm3g-3d8wALqx_EqBYI");
TokenParams tokenParams = new TokenParams {ClientId = "Bob"};
string tokenRequest = await realtime.Auth.CreateTokenRequestAsync(tokenParams);
/* ... issue the TokenRequest to a client ... */
ARTRealtime *realtime = [[ARTRealtime alloc] initWithKey:@"xVLyHw.0cALlg:derlO51V-Q8OvabUr8zAakOPSm3g-3d8wALqx_EqBYI"];
ARTTokenParams *tokenParams = [[ARTTokenParams alloc] initWithClientId:@"Bob"];
[realtime.auth createTokenRequest:tokenParams options:nil
callback:^(ARTTokenRequest *tokenRequest NSError *error) {
// ... issue the TokenRequest to a client ...
}];
let realtime = ARTRealtime(key: "xVLyHw.0cALlg:derlO51V-Q8OvabUr8zAakOPSm3g-3d8wALqx_EqBYI")
let tokenParams = ARTTokenParams(clientId: "Bob")
realtime.auth.createTokenRequest(tokenParams, options: nil) { tokenRequest, error in
// ... issue the TokenRequest to a client ...
}
API Reference
View the Authentication API Reference.