理解API密钥

Supabase 在创建项目时会提供两个默认密钥：anon 密钥和 service_role 密钥。您可以在 API 设置 中找到这两个密钥。

数据 API 设计用于与 Postgres 行级安全(RLS)协同工作。这些密钥都映射到 Postgres 角色。您可以在控制面板的 角色 部分找到 anon 用户和 service_role 用户。

这些密钥都是长期有效的 JWT。如果解码这些密钥，您会看到它们包含"角色"、"签发日期"和约10年后的"过期日期"。

1
2
3
4
5
{  "role": "anon",  "iat": 1625137684,  "exp": 1940713684}

anon 密钥#

anon 密钥的权限非常有限。您可以在 RLS策略 中使用它来允许未经认证的访问。例如，以下策略将允许对 profiles 表进行未经认证的访问：

1
2
3
create policy "Allow public access" on profiles to anon forselect  using (true);

同样地，要禁止访问可以使用：

1
2
3
create policy "Disallow public access" on profiles to anon forselect  using (false);

如果您使用 Supabase 认证，那么一旦用户登录，anon 角色将自动更新为 authenticated：

1
2
3
create policy "Allow access to authenticated users" on profiles to authenticated forselect  using (true);

service_role 密钥#

"service_role" 是一个预定义的 PostgreSQL 角色，拥有更高权限，专为执行各种管理和服务相关任务而设计。它可以绕过行级安全策略(Row Level Security)，因此应当仅在私有服务器上使用。

service_role 密钥的常见使用场景是在后端运行数据分析任务。为了支持基于用户ID的关联查询，通常需要授予该服务角色对 auth.users 表的读取权限：

1
2
3
grantselect  on table auth.users to service_role;

我们已与 GitHub 达成合作，扫描推送到公共仓库的 Supabase service_role 密钥。如果检测到任何具有 service_role 权限的密钥被推送到 GitHub，他们会将 API 密钥转发给我们，以便我们自动撤销检测到的密钥并通知您，保护您的数据免受恶意攻击。