Authentication and authorization

Systems establish authentication first, followed by authorization if implemented.

Authentication types

Authentication is the act of validating that users are who they claim to be. Two methods of authentication are common:

  • Passwords: If a user enters the correct credentials, the system assumes their identity is valid and grants access.

  • Authentication apps: Generate security codes via a third-party app to grant access.

Astra DB Serverless supports single sign-on with multiple identity providers:

  • Google: Use your Gmail or a G-Suite account to authenticate.

  • GitHub: Use your GitHub account to authenticate.

  • SAML: Use any SAML 2.0 capable Identity Provider (IdP) to authenticate. These include Microsoft Entra ID, Okta, OneLogin, Google, and Ping Identity. For more, see the SSO Documentation.

Existing Astra DB Serverless users

If you use GitHub for authentication and have the keep my email addresses private option enabled, you must:

  • Make your email public and change your password to switch to Astra DB Serverless local authentication.


  • Opt for a different IdP linked to the same email.

New Astra DB Serverless users

If you are registering with GitHub and have a private email, you must either make it public or choose an alternative authentication method.

What is authorization?

Authorization is the process of giving a user permission to access a specific resource or function. Other terms for this functionality are access control or client privilege.

Users must authenticate before Astra DB Serverless will authorize them. Authorization is generally controlled by the organization’s administrators.

Use an application token to authorize Astra DB Serverless connection

Authorize your application’s connection to your Astra DB Serverless database using an application token.

Create this token from either the Astra Portal or the DevOps API.

Table-based authentication and authorization

Table-based authentication and authorization uses the Stargate Auth API to generate an auth token based on a Cassandra username and password. The auth-table-based-service uses the generated auth token to allow Stargate API queries access to the Cassandra data.

By default, the token persists for 30 minutes with a sliding window. Each use of the token to authenticate resets the 30 minute window. A token created and used after 29 minutes will authenticate a request, but if 31 minutes passes before use, the token will no longer exist.

You can use the REST API to generate an auth token. This token is required in each subsequent request in the X-Cassandra-Token header.

curl -L -X POST '' \
  -H 'Content-Type: application/json' \
  --data-raw '{
    "username": "CLIENT_ID",
    "password": "CLIENT_SECRET"
You should receive a token in the response:

The authorization token returned must be either exported as an environment variable or entered into the HTTP Header.

  • REST or Document API (v2)

  • GraphQL

Store the auth token in an environment variable to make it easy to use with cURL.


Add the auth token to the HTTP Headers box in the GraphQL playground:


You have now successfully learned how to authenticate and authorize users in an application, including the use of passwords and auth tokens for secure resource access.

Was this helpful?

Give Feedback

How can we improve the documentation?

© 2024 DataStax | Privacy policy | Terms of use

Apache, Apache Cassandra, Cassandra, Apache Tomcat, Tomcat, Apache Lucene, Apache Solr, Apache Hadoop, Hadoop, Apache Pulsar, Pulsar, Apache Spark, Spark, Apache TinkerPop, TinkerPop, Apache Kafka and Kafka are either registered trademarks or trademarks of the Apache Software Foundation or its subsidiaries in Canada, the United States and/or other countries. Kubernetes is the registered trademark of the Linux Foundation.

General Inquiries: +1 (650) 389-6000,