Viewing API Keys

Scenarios

Supabase uses API keys to provide fine-grained access control for your project and determine which application components can access your project. API keys authenticate the identity of an application component (a web page, a mobile app, or a server) to enable it to access Supabase services. This section describes how to view the API key of a Supabase AI application.

Prerequisites

• Sign up for a Huawei Cloud account.
• If you need fine-grained management of resources on Huawei Cloud, use Identity and Access Management (IAM) to create IAM users and user groups, and grant them specific permissions so that the IAM users can obtain required permissions. For details, see Using IAM Roles or Policies to Grant Access to RDS.
• You must use a login account assigned the rds:aiApplication:listApiKey, rds:aiApplication:getApiKeyValue, rds:aiApplication:get, and rds:aiApplication:list actions.

API Key Functions

An API key is a unique identifier used to authenticate a client (such as a web page, a mobile app, or a server) and authorize it to access Supabase backend services (like database, authentication, and storage). API keys provide the first layer of authentication for data access, while Supabase Auth builds on this by providing further authentication for user logins. API keys distinguish applications, not users.

• Publishable Keys
  • A publishable key is used to identify the public components of an application. Public components run in environments where no confidential information can be protected, including the following:
    • Web pages: The key is embedded in the source code.
    • Mobile/Desktop apps: The key is packed in the compiled package or executable file.
    • CLIs, scripts, tools, or other pre-built executable files
    • Other publicly available APIs (that can return the key without additional authorization)
  • Interaction with Supabase Auth

    Using a publishable key does not mean that users are anonymous. You can use the publishable key to authenticate the application, while users obtain their own JWTs through Supabase Auth.

    Table 2 Interaction between Supabase application API keys and Supabase Auth

    Key	Whether Users Log in Through Supabase Auth	PostgreSQL Role for RLS
    Publishable key	No	anon
    Publishable key	Yes	authenticated

  • Security precautions

    A publishable key cannot prevent the following (because it is always possible to obtain the key from a public component):

    • Static or dynamic code analysis and reverse engineering
    • Browser network inspectors
    • Cross-site request forgery (CSRF), cross-site scripting (XSS), and phishing attacks
    • Man-in-the-middle (MITM) attacks
  • When you use a publishable key, access to your project data is protected by PostgreSQL through the built-in anon extension and authenticated roles. To ensure this, you need to pay attention to the following:
    • Enable RLS on all tables.
    • Regularly review RLS policies and check the permissions granted to the anon extension and authenticated roles.
    • Do not modify role attributes without fully understanding them.
    • Carefully review each security finding in the Security Advisor of your project.
• Secret Keys
  • Unlike a publishable key, a secret key allows high-level access to project data. It is only used in secure, developer-controlled components, such as:
    • Servers that implement their own authorization (Edge Functions, microservices, traditional/dedicated web servers)
    • Scheduled tasks, queue processors, and message subscribers
    • Management and backend tools (with only pre-authorization checks)
    • Data processing pipelines (such as analysis, reporting, backup, database synchronization pipelines)
  • Access control:

    Secret keys authorize access to project data through service_role, a built-in PostgreSQL role. This role has full access to project data and uses the BYPASSRLS attribute to skip all row-level security policies.

    Secret keys are an improved version of service role keys in the old JWT format, with the following anti-abuse checks added:

    • Secret keys cannot be used in a browser (detected by the User-Agent header), and HTTP 401 Unauthorized will always be returned.
    • If no secret keys are required, there is no need to create one.

• Keep your API keys secure to prevent security risks, potential attacks, and business losses.
• For details about how to use an API key, see Using the Supabase SDK.

Constraints

• An AI application has been created.
• For each API key type of a Supabase AI application, only one active key is supported. Each time a reset operation is successful, a new API key is created, and the old API key becomes invalid.

Procedure

1. Log in to the RDS console.
2. Click in the upper left corner and select a region.
3. In the navigation pane, choose AI App Dev Platform.
4. On the AI App Dev Platform page, click the target AI application name to open its details page.
5. In the navigation pane, choose API Key. The API key list is displayed.
   Figure 1 Application API key list
   

6. Locate an API key whose status is Normal and click Copy API Key Value in the Operation column to copy the key value to the clipboard.