<?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: Unity Catalog service credential get_token rejects api:// scope format — &amp;quot;not a valid URI&amp;q in Data Engineering</title>
    <link>https://community.databricks.com/t5/data-engineering/unity-catalog-service-credential-get-token-rejects-api-scope/m-p/165372#M55427</link>
    <description>&lt;P&gt;Hi&amp;nbsp;&lt;a href="https://community.databricks.com/t5/user/viewprofilepage/user-id/173462"&gt;@Oumeima&lt;/a&gt;&amp;nbsp;,&lt;BR /&gt;Thank you for the detailed reproduction. As per my understanding of the issue you are facing, your isolation of the problem is entirely correct.&lt;/P&gt;&lt;P&gt;This behavior is caused by an undocumented strict URI validation bug within the Databricks dbutils.credentials layer. When you request a token, the scope parameter (typically ending in /.default) tells Entra ID exactly which target API you want to access and automatically requests all permissions previously granted to your managed identity for that specific resource.&lt;/P&gt;&lt;P&gt;However, before passing this scope string to Azure to generate the token, the Databricks temporary-credentials path validates it. It currently expects standard Azure resource endpoints starting with https:// and inadvertently rejects api:// schemes as invalid URIs. Because this is an internal validation oversight rather than an intentional platform constraint, it is not mentioned in the official Databricks documentation.&lt;/P&gt;&lt;P&gt;To maintain strict compliance with your managed identity mandate without using client secrets, the most reliable workaround is to modify the Application ID URI of your internal API in the Azure Portal. Entra ID fully supports HTTPS-based Application ID URIs. By changing your exposed API's identifier from the default api://&amp;lt;client-id&lt;/P&gt;</description>
    <pubDate>Tue, 11 Aug 2026 13:13:03 GMT</pubDate>
    <dc:creator>ShamenParis</dc:creator>
    <dc:date>2026-08-11T13:13:03Z</dc:date>
    <item>
      <title>Unity Catalog service credential get_token rejects api:// scope format — "not a valid URI"</title>
      <link>https://community.databricks.com/t5/data-engineering/unity-catalog-service-credential-get-token-rejects-api-scope/m-p/165352#M55425</link>
      <description>&lt;P&gt;Calling get_token() on a Unity Catalog service credential fails for any scope using the api:// App ID URI format. Only https://-scheme resource scopes succeed. The same api:// scopes work correctly with a service principal.&lt;/P&gt;&lt;H2&gt;Reproduction&lt;/H2&gt;&lt;PRE&gt;credential = dbutils.credentials.getServiceCredentialsProvider(
    "managed-identity"
)

scopes = [
    "https://vault.azure.net/.default",
    "api://&amp;lt;domain&amp;gt;/.default",
    "api://&amp;lt;domain&amp;gt;",
    "api://&amp;lt;domain&amp;gt;/",
]

for scope in scopes:
    try:
        result = credential.get_token(scope)
        print(scope, "OK; expires:", result.expires_on)
    except Exception as error:
        print(scope, type(error).__name__, str(error))&lt;/PRE&gt;&lt;H3&gt;Result&lt;/H3&gt;&lt;P&gt;The first scope succeeds. &lt;STRONG&gt;Every api:// variant fails&lt;/STRONG&gt; with:&lt;/P&gt;&lt;PRE&gt;Error while retrieving temporary credentials: '&amp;lt;scope&amp;gt;' is not a valid URI&lt;/PRE&gt;&lt;P&gt;Substituting the app registration's Application (client) ID GUID — both as api://&amp;lt;client-id&amp;gt;/.default and as a bare &amp;lt;client-id&amp;gt;/.default — fails identically.&lt;/P&gt;&lt;P&gt;This isolates the failure to scope-string validation in the temporary-credentials path, not to the credential, the managed identity, or its permissions — the same credential object returns a valid token for the https:// scope in the same loop.&lt;/P&gt;&lt;H2&gt;Control test: the same scope succeeds via ClientSecretCredential&lt;/H2&gt;&lt;P&gt;On the same compute, in the same notebook, the identical api:// scope returns a valid token when requested through a service principal with azure.identity instead of the service credential provider:&lt;/P&gt;&lt;PRE&gt;from azure.identity import ClientSecretCredential

client_id = dbutils.secrets.get(scope="keyvault", key="client_id")
client_secret = dbutils.secrets.get(scope="keyvault", key="client_secret")
tenant_id = dbutils.secrets.get(scope="keyvault", key="tenant_id")

credential = ClientSecretCredential(
    tenant_id=tenant_id,
    client_id=client_id,
    client_secret=client_secret
)

scopes = ["api://&amp;lt;domain&amp;gt;/.default"]

for scope in scopes:
    try:
        result = credential.get_token(scope)
        print(scope, "OK; expires:", result.expires_on)
    except Exception as error:
        print(scope, type(error).__name__, str(error))&lt;/PRE&gt;&lt;H3&gt;Result&lt;/H3&gt;&lt;P&gt;api://&amp;lt;domain&amp;gt;/.default returns a token successfully.&lt;/P&gt;&lt;P&gt;This confirms the scope string is valid and that the app registration is correctly configured. The rejection originates solely in the Databricks temporary-credentials layer.&lt;/P&gt;&lt;H2&gt;Environments tested&lt;/H2&gt;&lt;UL&gt;&lt;LI&gt;Serverless compute&lt;/LI&gt;&lt;LI&gt;Classic compute, DBR 17.3 LTS&lt;/LI&gt;&lt;/UL&gt;&lt;P&gt;Identical behavior on both.&lt;/P&gt;&lt;H2&gt;Business impact&lt;/H2&gt;&lt;P&gt;Our security policy mandates managed identities. Unity Catalog service credentials are therefore our only supported path for machine-to-machine authentication from Databricks to internal APIs. This validation blocks that path entirely for any internal API using the default api:// identifier URI.&lt;/P&gt;&lt;P&gt;The ClientSecretCredential approach shown above works, but is not a viable workaround for us: it requires storing and rotating a client secret, which is precisely what the managed-identity mandate exists to avoid.&lt;/P&gt;&lt;H2&gt;Questions&lt;/H2&gt;&lt;OL&gt;&lt;LI&gt;Is this a known limitation, or a bug in scope validation for temporary service credentials?&lt;/LI&gt;&lt;LI&gt;If intentional, where is the accepted resource-URI format documented? We found no mention of a scheme restriction in the service credentials documentation.&lt;/LI&gt;&lt;/OL&gt;</description>
      <pubDate>Tue, 11 Aug 2026 12:00:46 GMT</pubDate>
      <guid>https://community.databricks.com/t5/data-engineering/unity-catalog-service-credential-get-token-rejects-api-scope/m-p/165352#M55425</guid>
      <dc:creator>Oumeima</dc:creator>
      <dc:date>2026-08-11T12:00:46Z</dc:date>
    </item>
    <item>
      <title>Re: Unity Catalog service credential get_token rejects api:// scope format — "not a valid URI&amp;q</title>
      <link>https://community.databricks.com/t5/data-engineering/unity-catalog-service-credential-get-token-rejects-api-scope/m-p/165372#M55427</link>
      <description>&lt;P&gt;Hi&amp;nbsp;&lt;a href="https://community.databricks.com/t5/user/viewprofilepage/user-id/173462"&gt;@Oumeima&lt;/a&gt;&amp;nbsp;,&lt;BR /&gt;Thank you for the detailed reproduction. As per my understanding of the issue you are facing, your isolation of the problem is entirely correct.&lt;/P&gt;&lt;P&gt;This behavior is caused by an undocumented strict URI validation bug within the Databricks dbutils.credentials layer. When you request a token, the scope parameter (typically ending in /.default) tells Entra ID exactly which target API you want to access and automatically requests all permissions previously granted to your managed identity for that specific resource.&lt;/P&gt;&lt;P&gt;However, before passing this scope string to Azure to generate the token, the Databricks temporary-credentials path validates it. It currently expects standard Azure resource endpoints starting with https:// and inadvertently rejects api:// schemes as invalid URIs. Because this is an internal validation oversight rather than an intentional platform constraint, it is not mentioned in the official Databricks documentation.&lt;/P&gt;&lt;P&gt;To maintain strict compliance with your managed identity mandate without using client secrets, the most reliable workaround is to modify the Application ID URI of your internal API in the Azure Portal. Entra ID fully supports HTTPS-based Application ID URIs. By changing your exposed API's identifier from the default api://&amp;lt;client-id&lt;/P&gt;</description>
      <pubDate>Tue, 11 Aug 2026 13:13:03 GMT</pubDate>
      <guid>https://community.databricks.com/t5/data-engineering/unity-catalog-service-credential-get-token-rejects-api-scope/m-p/165372#M55427</guid>
      <dc:creator>ShamenParis</dc:creator>
      <dc:date>2026-08-11T13:13:03Z</dc:date>
    </item>
  </channel>
</rss>

