<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>topic Re: Group-based auth with Lakebase Data API in Lakebase Discussions</title>
    <link>https://community.databricks.com/t5/lakebase-discussions/group-based-auth-with-lakebase-data-api/m-p/170881#M138</link>
    <description>&lt;P&gt;Hi Malthe, you're right, the Data API doesn't support group roles yet.&lt;/P&gt;
&lt;P&gt;The reason is how it authenticates. Over a normal Postgres connection you can log in as a group role (created with `databricks_create_role('&amp;lt;group&amp;gt;', 'GROUP')`). The Data API works differently: it always connects as `authenticator` and then switches to the role named in the caller's OAuth token. That token identifies the user or service principal, not their groups, so a principal whose only access is through a group role gets a `401 PGRST301 invalid token permissions`. The team knows about the gap and is working on it, but there's no public date yet.&lt;/P&gt;
&lt;P&gt;Until then, you can use Postgres role inheritance so all grants live in one place. I've tested this pattern against a Data API endpoint with service principals:&lt;/P&gt;
&lt;P&gt;-- One-off: a NOLOGIN role that holds the privileges&lt;BR /&gt;CREATE ROLE app_rw NOLOGIN;&lt;BR /&gt;GRANT USAGE ON SCHEMA public TO app_rw;&lt;BR /&gt;GRANT SELECT, INSERT, UPDATE, DELETE ON ALL TABLES IN SCHEMA public TO app_rw;&lt;BR /&gt;ALTER DEFAULT PRIVILEGES IN SCHEMA public&lt;BR /&gt;GRANT SELECT, INSERT, UPDATE, DELETE ON TABLES TO app_rw;&lt;/P&gt;
&lt;P&gt;-- Per identity: three statements, no table grants&lt;BR /&gt;SELECT databricks_create_role('&amp;lt;user-email or SP application ID&amp;gt;', 'USER' | 'SERVICE_PRINCIPAL');&lt;BR /&gt;GRANT app_rw TO "&amp;lt;identity&amp;gt;";&lt;BR /&gt;GRANT "&amp;lt;identity&amp;gt;" TO authenticator;&lt;/P&gt;
&lt;P&gt;When the Data API switches to the caller's role, that role inherits everything granted to app_rw. Tables not granted to app_rw still return 403. REVOKE app_rw FROM "&amp;lt;identity&amp;gt;" removes access straight away, and thanks to the default privileges, tables you create later are covered too. New tables can take a short while to appear in the Data API while its schema cache refreshes.&lt;/P&gt;
&lt;P&gt;Schema and table permissions are then managed once, and onboarding someone new is just the three statements above. You can also script that part: pull your group's members from the SCIM API and run the statements for anyone who doesn't have a role yet. That gives you a rough group sync until native support arrives.&lt;/P&gt;
&lt;P&gt;Docs:&lt;BR /&gt;- Data API auth: &lt;A href="https://docs.databricks.com/aws/en/oltp/projects/data-api" target="_self"&gt;https://docs.databricks.com/aws/en/oltp/projects/data-api&lt;/A&gt;&lt;BR /&gt;- Postgres roles (incl. group roles): &lt;A href="https://docs.databricks.com/aws/en/oltp/projects/postgres-roles" target="_self"&gt;https://docs.databricks.com/aws/en/oltp/projects/postgres-roles&lt;/A&gt;&lt;/P&gt;</description>
    <pubDate>Tue, 06 Oct 2026 16:40:40 GMT</pubDate>
    <dc:creator>tom_n</dc:creator>
    <dc:date>2026-10-06T16:40:40Z</dc:date>
    <item>
      <title>Group-based auth with Lakebase Data API</title>
      <link>https://community.databricks.com/t5/lakebase-discussions/group-based-auth-with-lakebase-data-api/m-p/170710#M137</link>
      <description>&lt;P&gt;While Lakebase &lt;A href="https://learn.microsoft.com/en-us/azure/databricks/oltp/projects/postgres-roles#group-based-auth" target="_self"&gt;supports group-based authentication&lt;/A&gt;, this doesn't seem to have carried over to Lakebase Data API.&lt;/P&gt;&lt;P&gt;Here, we must assign on the individual user or service principal,&lt;/P&gt;&lt;UL&gt;&lt;LI&gt;Create principal&lt;/LI&gt;&lt;LI&gt;Setup authenticator access&lt;/LI&gt;&lt;LI&gt;Schema- and table grants&lt;/LI&gt;&lt;/UL&gt;&lt;P&gt;This means that it becomes rather a big administrative burden to set up for multiple users or service principals, as well as disorganized.&lt;/P&gt;&lt;P&gt;Will this be supported in the future?&lt;/P&gt;</description>
      <pubDate>Tue, 06 Oct 2026 09:15:29 GMT</pubDate>
      <guid>https://community.databricks.com/t5/lakebase-discussions/group-based-auth-with-lakebase-data-api/m-p/170710#M137</guid>
      <dc:creator>Malthe</dc:creator>
      <dc:date>2026-10-06T09:15:29Z</dc:date>
    </item>
    <item>
      <title>Re: Group-based auth with Lakebase Data API</title>
      <link>https://community.databricks.com/t5/lakebase-discussions/group-based-auth-with-lakebase-data-api/m-p/170881#M138</link>
      <description>&lt;P&gt;Hi Malthe, you're right, the Data API doesn't support group roles yet.&lt;/P&gt;
&lt;P&gt;The reason is how it authenticates. Over a normal Postgres connection you can log in as a group role (created with `databricks_create_role('&amp;lt;group&amp;gt;', 'GROUP')`). The Data API works differently: it always connects as `authenticator` and then switches to the role named in the caller's OAuth token. That token identifies the user or service principal, not their groups, so a principal whose only access is through a group role gets a `401 PGRST301 invalid token permissions`. The team knows about the gap and is working on it, but there's no public date yet.&lt;/P&gt;
&lt;P&gt;Until then, you can use Postgres role inheritance so all grants live in one place. I've tested this pattern against a Data API endpoint with service principals:&lt;/P&gt;
&lt;P&gt;-- One-off: a NOLOGIN role that holds the privileges&lt;BR /&gt;CREATE ROLE app_rw NOLOGIN;&lt;BR /&gt;GRANT USAGE ON SCHEMA public TO app_rw;&lt;BR /&gt;GRANT SELECT, INSERT, UPDATE, DELETE ON ALL TABLES IN SCHEMA public TO app_rw;&lt;BR /&gt;ALTER DEFAULT PRIVILEGES IN SCHEMA public&lt;BR /&gt;GRANT SELECT, INSERT, UPDATE, DELETE ON TABLES TO app_rw;&lt;/P&gt;
&lt;P&gt;-- Per identity: three statements, no table grants&lt;BR /&gt;SELECT databricks_create_role('&amp;lt;user-email or SP application ID&amp;gt;', 'USER' | 'SERVICE_PRINCIPAL');&lt;BR /&gt;GRANT app_rw TO "&amp;lt;identity&amp;gt;";&lt;BR /&gt;GRANT "&amp;lt;identity&amp;gt;" TO authenticator;&lt;/P&gt;
&lt;P&gt;When the Data API switches to the caller's role, that role inherits everything granted to app_rw. Tables not granted to app_rw still return 403. REVOKE app_rw FROM "&amp;lt;identity&amp;gt;" removes access straight away, and thanks to the default privileges, tables you create later are covered too. New tables can take a short while to appear in the Data API while its schema cache refreshes.&lt;/P&gt;
&lt;P&gt;Schema and table permissions are then managed once, and onboarding someone new is just the three statements above. You can also script that part: pull your group's members from the SCIM API and run the statements for anyone who doesn't have a role yet. That gives you a rough group sync until native support arrives.&lt;/P&gt;
&lt;P&gt;Docs:&lt;BR /&gt;- Data API auth: &lt;A href="https://docs.databricks.com/aws/en/oltp/projects/data-api" target="_self"&gt;https://docs.databricks.com/aws/en/oltp/projects/data-api&lt;/A&gt;&lt;BR /&gt;- Postgres roles (incl. group roles): &lt;A href="https://docs.databricks.com/aws/en/oltp/projects/postgres-roles" target="_self"&gt;https://docs.databricks.com/aws/en/oltp/projects/postgres-roles&lt;/A&gt;&lt;/P&gt;</description>
      <pubDate>Tue, 06 Oct 2026 16:40:40 GMT</pubDate>
      <guid>https://community.databricks.com/t5/lakebase-discussions/group-based-auth-with-lakebase-data-api/m-p/170881#M138</guid>
      <dc:creator>tom_n</dc:creator>
      <dc:date>2026-10-06T16:40:40Z</dc:date>
    </item>
  </channel>
</rss>

