http://starrocks.io logo
Join Slack
Powered by
<@U0A71G31CDV> Hello we try to create security int...
# questions-and-troubleshooting
z
@Rocky Hello we try to create security integration on top of starrocks via OAuth2.0 and Azure AD but we get error 
StarRocks OAuth2 authentication
 
Failed
 
Can not get specified principal preferred_username
 any ideas what the reason can be? :(
r
The error 
Can not get specified principal preferred_username
 indicates that StarRocks successfully received a JSON Web Token (JWT) from Azure AD, but it could not find a claim (field) named 
preferred_username
inside that token to identify the user. In Azure AD (Microsoft Entra ID), the 
preferred_username
claim is not always included by default. Here are the common reasons and how to fix it: 1. Missing "profile" Scope In Azure AD v2.0, the 
preferred_username
claim is only included if the 
profile
 scope is requested during the authentication flow. * Problem: Some versions of StarRocks may default to requesting only the 
openid
scope. * Solution: Check if you can append 
+profile
to your 
auth_server_url
in the security integration properties (e.g., 
.../authorize?scope=openid+profile+email
). If StarRocks generates the scope internally and it's not configurable, you must use Method 2. 2. Configure "Optional Claims" in Azure Portal (Recommended) You can force Azure AD to include the 
preferred_username
claim regardless of the requested scopes by configuring it as an optional claim in your App Registration: 1. Go to the Azure Portal > Microsoft Entra ID > App registrations. 2. Select your application. 3. Go to Token configuration in the left menu. 4. Click + Add optional claim. 5. Select ID (and Access if needed) as the token type. 6. Check preferred_username from the list and click Add. 7. (Optional) If prompted, turn on the "Microsoft Graph profile permission". 3. Change the Principal Field in StarRocks If you prefer to use a claim that is already present in your token (like 
sub
or 
upn
), you can update your StarRocks configuration: * Check your token: Use a tool like jwt.io to decode the token you are getting from Azure. Look for a field that contains the username you want to use in StarRocks. * Update StarRocks: Change the 
principal_field
property to match a field that exists in your token.
Copy code
sql
    -- Example changing to 'sub' (Azure's unique ID) or 'upn'
    ALTER SECURITY INTEGRATION <your_integration_name>
    SET PROPERTIES ("principal_field" = "sub");
_Note: 
sub
in Azure is usually a non-human-readable GUID. If you want human-readable names, 
preferred_username
or 
email
are better choices._ 4. Verify Azure AD Endpoint Version Azure AD has v1.0 and v2.0 endpoints. * v1.0 typically uses 
unique_name
or 
upn
. * v2.0 uses 
preferred_username
. Ensure your 
auth_server_url
and 
token_server_url
consistently use the same version (look for 
/v2.0/
in the URL). Summary Checklist * Does your decoded JWT contain 
preferred_username
? (Use jwt.io) * Is the 
preferred_username
value exactly the same as the 
username
you created in StarRocks? * Have you added 
preferred_username
as an Optional Claim in the Azure App Registration? If the issue persists, try setting 
principal_field
to 
sub
as a test to see if the authentication completes, even if the username mapping fails to match. References • administration/management/FE_configuration.md
z
@Rocky when preferred username/upn are coming with email suffix like user@mail.com how should we create starrocks login in that case to match it?
r
To match a principal that includes an email suffix (like 
<mailto:user@mail.com|user@mail.com>
), you must create the StarRocks user with the exact, full string provided in the JWT token. StarRocks does not currently support automatic domain stripping or regex-based username transformation in its OAuth2.0 integration. 1. Create the User with Quotes When creating the user in StarRocks, you must wrap the email address in single quotes. StarRocks will treat the entire string (including the 
@
and domain) as the 
username
part of the identity.
Copy code
sql
-- The identity created here is '<mailto:user@mail.com|user@mail.com>'@'%'
CREATE USER '<mailto:user@mail.com|user@mail.com>' IDENTIFIED WITH authentication_oauth2;
2. Verify the 
principal_field
 Ensure your Security Integration is configured to look at the correct claim that contains the full email. In Azure AD, this is typically 
preferred_username
or 
upn
.
Copy code
sql
-- Check your integration properties
SHOW SECURITY INTEGRATIONS;

-- If needed, update it to use the correct field
ALTER SECURITY INTEGRATION <your_integration_name> 
SET PROPERTIES ("principal_field" = "preferred_username");
3. Granting Privileges When granting roles to this user, continue to use the full quoted identity:
Copy code
sql
GRANT role_name TO '<mailto:user@mail.com|user@mail.com>'@'%';
Important Considerations: * Case Sensitivity: JWT claims are usually case-sensitive. If Azure AD sends 
<mailto:User@Mail.com|User@Mail.com>
, the StarRocks username must match that exact casing. * Decoded Token Check: If you are unsure exactly what string Azure is sending, decode your JWT (using a tool like jwt.io) and copy the value of the 
preferred_username
field exactly. * No Auto-Provisioning: StarRocks requires the user to exist in its internal metadata before they can log in via OAuth2.0. There is no "Just-In-Time" (JIT) user creation feature for OAuth2.0 at this time; you must pre-create the user accounts or use Group Mapping (RBAC) if you want to manage permissions via Azure AD groups instead of individual users. Using Group Mapping (Alternative) If you have many users, instead of creating each 
'<mailto:user@mail.com|user@mail.com>'
, you can map Azure AD Groups to StarRocks Roles. This allows any user in an Azure group to log in and automatically inherit the correct StarRocks role. This requires configuring a 
group_field
in your integration. References • administration/user_privs/authentication/oauth2_authentication.md • administration/user_privs/authentication/security_integration.md
z
@Rocky but starrocks cant creaate user with @ it says "[42000][1064] Getting analyzing error. Detail message: invalid user name:"
r
The reason you are seeing this error is due to a fundamental naming restriction in StarRocks: 1. The "@" Character is Restricted According to the StarRocks System Limits, a username can only consist of digits (0-9), letters (a-z or A-Z), and underscores (_). Because an email address (e.g., 
<mailto:user@mail.com|user@mail.com>
) contains the 
@
symbol and often dots 
.
, it is considered an "invalid user name" by the StarRocks SQL parser, even if you wrap it in quotes. ────────── 2. The Solution: Use Security Integration (No Manual User Creation) If you are using a Security Integration (available in StarRocks v3.2+), the recommended approach is to not manually create the users at all. When you use a Security Integration with an 
authentication_chain
, StarRocks authenticates the user against Azure AD and maps them to roles dynamically. * How it works: You create a Security Integration and a Group Provider. * Benefit: You don't have to run 
CREATE USER
for every person. StarRocks handles the login automatically as long as the JWT is valid. * Permissions: You grant privileges to Roles, and then map your Azure AD Groups to those Roles. Example Setup:
Copy code
sql
-- 1. Create the Security Integration (matches your JWT)
CREATE SECURITY INTEGRATION azure_ad_integration
PROPERTIES (
    "type" = "authentication_oauth2",
    "auth_server_url" = "...",
    "principal_field" = "preferred_username", -- This can be the email!
    ...
);

-- 2. Create a Group Provider to map Azure Groups to StarRocks Roles
CREATE GROUP PROVIDER azure_groups
PROPERTIES (
    "type" = "oauth2",
    "security_integration" = "azure_ad_integration"
);

-- 3. Map an Azure Group ID to a StarRocks Role
-- You don't need a '<mailto:user@mail.com|user@mail.com>' account; the user gets 'analyst_role' via the group.
GRANT analyst_role TO EXTERNAL GROUP "azure-group-object-id" ANY PROVIDER;
────────── 3. Alternative: Change the "Principal Field" If you absolutely must create individual users manually in StarRocks, you cannot use the email address as the identifier. You must switch the 
principal_field
to a claim that follows StarRocks naming rules (no 
@
). * Option A: Use the 
sub
or 
oid
claim. In Azure AD, the 
sub
(Subject) or 
oid
(Object ID) is a unique alphanumeric GUID (e.g., 
38f2...
). 1. Update your Integration: 
SET PROPERTIES ("principal_field" = "oid")
2. Create the User: 
CREATE USER '38f2...' IDENTIFIED WITH authentication_oauth2;
* Option B: Configure an Optional Claim. In the Azure Portal, you can add a custom "Optional Claim" to your App Registration (like 
nickname
or a custom employee ID) that does not contain special characters, and use that as your 
principal_field
. Summary * Don't try to 
CREATE USER '<mailto:user@mail.com|user@mail.com>'
. It will always fail the syntax check. * Do use Group Mapping so you don't have to create users manually. * Or switch your 
principal_field
to a claim that contains only letters, numbers, and underscores (like 
oid
). References • administration/user_privs/authentication/oauth2_authentication.md • administration/management/FE_configuration.md • administration/user_privs/authentication/security_integration.md
z
@Rocky ok so what values can 
principal_field
have?
r
The 
principal_field
property tells StarRocks which field (claim) inside the Azure AD JWT token it should look at to find the user's name. The value of the 
principal_field
property can be the name of any claim present in your token. However, for the login to succeed, the content of that claim must follow StarRocks' naming rules (letters, numbers, and underscores only). Here are the common values you can use for 
principal_field
with Azure AD: 1. 
oid
or 
sub
(Recommended) * What it is: These are unique identifiers (GUIDs) for the user in Azure AD (e.g., 
5e3a89...
). * Why use it: They contain only alphanumeric characters and dashes (StarRocks handles dashes in some contexts, but to be safe, standard GUIDs work well). They never contain 
@
or 
.
symbols. * StarRocks setup:
Copy code
sql
    -- 1. Set the field
    ALTER SECURITY INTEGRATION azure_integration SET PROPERTIES ("principal_field" = "oid");

    -- 2. Create the user using the GUID from Azure
    CREATE USER '5e3a89...' IDENTIFIED WITH authentication_oauth2;
2. 
nickname
 * What it is: A standard OIDC claim. * Why use it: If you configure your Azure App Registration to include the 
nickname
claim and ensure it is a simple string (like 
jdoe
), it will work perfectly with StarRocks' 
CREATE USER jdoe
. 3. 
preferred_username
(Default) * What it is: Usually the user's email or UPN. * The Problem: As you found, if this contains 
@
or 
.
, StarRocks cannot create a local user for it. You can only use this if your Azure AD configuration ensures 
preferred_username
is a simple string (which is rare for Azure). 4. Any Custom Claim * If your organization has a custom claim in Azure AD for "EmployeeID" or "InternalUsername", you can point 
principal_field
to that. ────────── How to decide? 1. Decode your token: Go to jwt.io, paste your token, and look at the "Payload" section. 2. Find a field that contains only letters, numbers, or underscores. 3. Update StarRocks: Set 
principal_field
to that field name and use its value in your 
CREATE USER
statement. If you want to use emails anyway: If your business requirement is that users must use their email addresses, you cannot use the 
CREATE USER
approach. You must use Group Mapping (RBAC). In this mode: 1. You don't create individual users in StarRocks. 2. You map Azure AD Groups to StarRocks Roles. 3. StarRocks handles the identity internally, bypassing the manual 
CREATE USER
syntax restriction. References • administration/user_privs/authentication/oauth2_authentication.md • administration/user_privs/authentication/security_integration.md • administration/management/FE_configuration.md References • administration/management/FE_configuration.md • administration/user_privs/authentication/security_integration.md • administration/user_privs/authentication/oauth2_authentication.md
z
@Rocky but it says "Can not get specified principal oid" and may be principal_field ='oid' is incorrect and it should be openid?
r
To resolve the error "Can not get specified principal oid", you need to understand that StarRocks is looking for a key named 
oid
in the JSON payload of your JWT token and failing to find it. 1. Why "openid" is incorrect 
openid
is an OAuth2 scope (a permission you request), not a claim (a field containing user data). Setting 
principal_field = 'openid'
will not work because there is no field named "openid" inside the token that contains a username. 2. Why "oid" might be missing In Azure AD, the 
oid
(Object ID) claim is the most stable unique identifier, but it might be missing from your token if: * You are using v2.0 Access Tokens for a custom API (where 
sub
is used instead). * Your App Registration is not configured to include the "Object ID" claim in the token. 3. How to find the correct field You must inspect the token your browser/client is actually sending to StarRocks: 1. Capture the JWT token (from the URL after redirect or your browser's network logs). 2. Paste it into *jwt.io*. 3. Look at the Payload section. You need to find a field that: * Exists (so StarRocks can find it). * Does not contain 
@
or 
.
 (so StarRocks 
CREATE USER
syntax accepts it). Common Azure AD claims to look for: * `sub`: (Subject) Usually a unique alphanumeric string. This is the safest bet. * `oid`: (Object ID) A GUID like 
5e3a89...
. If it's missing in 
<http://jwt.io|jwt.io>
, you can't use it in StarRocks. * 
uti
or `rh`: These are internal Azure IDs (not recommended, but valid for testing). 4. Updating StarRocks Once you find a field in 
<http://jwt.io|jwt.io>
that has a clean value (e.g., 
sub
has 
XyZ123
), update your configuration:
Copy code
sql
-- Update the integration to look for the 'sub' field instead
ALTER SECURITY INTEGRATION <your_integration_name> 
SET PROPERTIES ("principal_field" = "sub");

-- Create the user using the value found in the 'sub' field
CREATE USER 'XyZ123' IDENTIFIED WITH authentication_oauth2;
5. The "Best Practice" Recommendation If you want users to log in with their email-style identities without hitting the 
invalid user name
error, you should use RBAC (Group Mapping). With Group Mapping, you don't create individual users in StarRocks. Instead, you map an Azure AD Group to a StarRocks Role. StarRocks will then allow 
<mailto:user@mail.com|user@mail.com>
to log in because it validates the group membership rather than looking for a local user object named 
<mailto:user@mail.com|user@mail.com>
. Required Integration Property for Group Mapping:
Copy code
sql
-- This tells StarRocks which field contains the group IDs (usually 'groups')
"group_field" = "groups"
Summary: * Check jwt.io to see what claims are actually in your token. * Use 
sub
if 
oid
is missing. * Avoid 
openid
as it is not a claim. * Consider Group Mapping to avoid 
CREATE USER
syntax issues entirely. References • administration/management/FE_configuration.md • administration/user_privs/authentication/oauth2_authentication.md
z
@Rocky I checked token body and Id token and access token both include oid key but starrocks still says "Can not get specified principal oid"
r
The error message 
"Can not get specified principal oid"
confirms that StarRocks is correctly reading your configuration for 
principal_field
, but it is failing to find a key named exactly 
oid
in the token it received. Even if you see 
oid
when you manually decode a token in 
<http://jwt.io|jwt.io>
, StarRocks might still fail due to one of the following Azure AD-specific behaviors: 1. ID Token vs. Access Token StarRocks typically extracts the principal from the ID Token (used for identity) rather than the Access Token (used for permissions). * In some Azure AD configurations (especially v2.0), the claims present in the Access Token are not identical to those in the ID Token. * Action: In 
<http://jwt.io|jwt.io>
, make sure you are looking at the ID Token. If 
oid
is missing there, StarRocks cannot find it. 2. Claim Namespaces (v1.0 vs v2.0) If you are using Azure AD v1.0 endpoints, the claim for the Object ID is often not just 
oid
, but a full URI. * Example: 
<http://schemas.microsoft.com/identity/claims/objectidentifier>
* Action: Check your token in 
<http://jwt.io|jwt.io>
and look for the literal key name. If it looks like a URL, you must use that full URL as the 
principal_field
value in StarRocks, or switch your Azure App Registration to use v2.0 tokens. 3. Try the 
sub
Claim The 
sub
(Subject) claim is the mandatory standard for OpenID Connect and is almost always present as a simple alphanumeric string. * Action: Try changing your configuration to:
Copy code
sql
    ALTER SECURITY INTEGRATION your_integration_name
    SET PROPERTIES ("principal_field" = "sub");
Then, create the user using the 
sub
value from your token. 4. Check the FE Log for Available Claims When this error occurs, StarRocks usually logs the failure. If you have access to the StarRocks FE logs (
fe.warn.log
or 
fe.log
), look for the error. Often, StarRocks will print the actual keys it found in the token right before it says it couldn't find the principal. This will tell you exactly what the key is named (e.g., it might be 
OID
in uppercase or a different field entirely). 5. Verify Scopes If your StarRocks configuration (or the client plugin you are using) does not request the 
profile
or 
openid
scopes, Azure might return a "thin" token that excludes the 
oid
claim. * Action: Ensure your 
auth_server_url
includes 
scope=openid+profile
or that your security integration has these scopes allowed. Summary of what to try next: 1. Test `sub`: It is the most reliable "no-special-character" field in Azure. 2. Check FE Logs: This is the only way to see exactly what JSON StarRocks is seeing. 3. Check Token Version: Ensure you are using the v2.0 endpoints (
.../oauth2/v2.0/authorize
) as they follow OIDC standards more strictly than v1.0. References • administration/user_privs/authentication/oauth2_authentication.md • administration/user_privs/authentication/security_integration.md • administration/management/FE_configuration.md References • administration/management/FE_configuration.md • administration/user_privs/authentication/oauth2_authentication.md
z
@Rocky I have that in my java plugin for datagrip " String authUrl = authServerUrl + "?response_type=code" + "&client_id=" + URLEncoder.encode(clientId, StandardCharsets.UTF_8) + "&redirect_uri=" + URLEncoder.encode(redirectUrl, StandardCharsets.UTF_8) + "&state=" + connectionId + "&scope=openid";"
r
The error persists because StarRocks is likely looking at the Access Token, while the 
oid
claim you see might be in the ID Token, or it is being excluded from the Access Token because of the restricted scope in your Java code. In Azure AD, requesting only 
scope=openid
is the bare minimum and often results in a "thin" token. To fix this, you should make two changes: 1. Update your Java Code (Add Scopes) Add the 
profile
and 
email
scopes. The 
profile
scope is specifically what tells Azure AD to include additional identity claims like 
oid
, 
preferred_username
, and 
nickname
in the tokens. Update your code to:
Copy code
java
String authUrl = authServerUrl +
                "?response_type=code" +
                "&client_id=" + URLEncoder.encode(clientId, StandardCharsets.UTF_8) +
                "&redirect_uri=" + URLEncoder.encode(redirectUrl, StandardCharsets.UTF_8) +
                "&state=" + connectionId +
                "&scope=openid+profile+email"; // Added profile and email
2. Verify the 
principal_field
name in the Access Token When using StarRocks with a plugin (like DataGrip), the plugin typically sends the Access Token to StarRocks. * Open jwt.io and paste the Access Token (not the ID Token). * Check if the key is exactly 
oid
. * If the Access Token does not have 
oid
even after adding the 
profile
scope, look for the 
sub
key. The 
sub
key is the standard "Subject" identifier and is guaranteed to be in every OpenID Connect token. 3. Alternative: Use the 
sub
claim If 
oid
continues to be problematic, switch to 
sub
. It is functionally equivalent for Azure AD (a unique, immutable ID for the user) but is more reliably present across different token types. Step A: Update StarRocks Integration
Copy code
sql
ALTER SECURITY INTEGRATION azure_integration 
SET PROPERTIES ("principal_field" = "sub");
Step B: Update your User Find the 
sub
value for your user in jwt.io and recreate the user:
Copy code
sql
CREATE USER 'your-sub-guid-here' IDENTIFIED WITH authentication_oauth2;
Why this happens Azure AD v2.0 tokens treat the 
oid
and 
sub
claims differently depending on the "Audience" (
aud
) of the token. By requesting the 
profile
scope, you ensure that the identity provider includes the claims necessary to identify the user's "profile" (which includes the Object ID in Azure's case). References • administration/user_privs/authentication/oauth2_authentication.md • administration/management/FE_configuration.md • administration/user_privs/authentication/security_integration.md References • administration/management/FE_configuration.md • administration/user_privs/authentication/oauth2_authentication.md
z
@Rocky I checked and both id token and acces token include 
oid
in their payload
r
Even though you see the 
oid
key in your token, StarRocks may be failing to extract it due to one of the following reasons. Since the error message specifically says "Can not get specified principal oid", it means the StarRocks FE has successfully parsed the JWT but literally did not find a top-level key named 
oid
in the JSON payload it is looking at. 1. The Scope and Token Type Your Java code uses 
&scope=openid
. In Azure AD: * 
scope=openid
typically returns an ID Token that contains 
oid
. * However, if your Java plugin is passing the Access Token to StarRocks, and that Access Token is intended for the Microsoft Graph API (the default when no custom scope is provided), it might be an "opaque" token or a JWT with a different claim set than the ID Token. * Fix: Try changing your scope to 
&scope=openid+profile+email
. The 
profile
scope is what officially requests identity claims like 
oid
. 2. Is it 
oid
or a Namespaced Claim? Depending on whether you are using the Azure AD v1.0 or v2.0 endpoint, the claim name might be different. * v2.0 (Recommended): The key is 
oid
. * v1.0: The key is often the full URI: 
<http://schemas.microsoft.com/identity/claims/objectidentifier>
. * Verification: In jwt.io, look at the key name itself. If it looks like a URL, you must use that entire URL as your 
principal_field
in StarRocks. 3. Case Sensitivity and Quotes Ensure there are no hidden formatting issues in your 
CREATE USER
or 
ALTER SECURITY INTEGRATION
command. * Incorrect: 
SET PROPERTIES ("principal_field" = "'oid'")
(Double quotes inside single quotes). * Correct: 
SET PROPERTIES ("principal_field" = "oid")
. * Check Case: Check if the token shows 
OID
instead of 
oid
. 4. Use the 
sub
Claim (The Recommended Fix) The 
sub
(Subject) claim is a mandatory part of the OpenID Connect standard and is guaranteed to be a top-level, simple string in both ID and Access tokens from Azure. 1. Check your token in 
<http://jwt.io|jwt.io>
and find the 
sub
value (it will be a unique string). 2. Update StarRocks:
Copy code
sql
    -- If using Security Integration
    ALTER SECURITY INTEGRATION <name> SET PROPERTIES ("principal_field" = "sub");

    -- If defined on the user directly
    ALTER USER <user> IDENTIFIED WITH authentication_oauth2 AS '{"principal_field": "sub", ...}';
3. Ensure the StarRocks username matches that 
sub
value. 5. Inspect the FE Logs This is the most definitive way to solve the problem. When StarRocks throws this error, it often logs the actual JSON keys it found in the token just before the error in the FE log file. * Check 
fe/log/fe.warn.log
or 
fe/log/fe.log
. * Look for the line containing 
Can not get specified principal
. * The log will often show you exactly what StarRocks "sees" in the token payload. Summary Checklist * Verify Endpoint: Are you using 
<https://login.microsoftonline.com/<tenant>/oauth2/v2.0/token>
? (v2.0 is preferred). * Check Access Token Audience: If you are passing an Access Token, ensure you have "Exposed an API" in Azure and are requesting a scope like 
api://<client-id>/access_as_user
. * Try `sub`: It is much more stable across different Azure configurations than 
oid
. References • administration/user_privs/authentication/oauth2_authentication.md • administration/management/FE_configuration.md • administration/user_privs/authentication/security_integration.md References • faq/Sql_faq.md • administration/user_privs/authorization/User_privilege.md
z
@Rocky fe logs say "2026-05-28 165456.524+05:00 INFO (starrocks-http-pool-0|208) [BaseAction.getAuthorizationInfo():333] parse auth info failed, url /favicon.ico"
r
The log message you found—`parse auth info failed, url /favicon.ico`—is a red herring. It simply means a web browser (likely yours) tried to load the StarRocks Web UI icon without being authenticated. It is unrelated to your JDBC/DataGrip plugin error. The error "Can not get specified principal oid" is the one to solve. It means StarRocks successfully parsed the JWT but found that the key 
oid
was missing from the JSON payload it received. Since you verified that 
oid
exists in 
<http://jwt.io|jwt.io>
, here is why StarRocks might still be failing to see it: 1. Access Token vs. ID Token (Most Likely) Most JDBC plugins for StarRocks pass the Access Token to the server for authentication, not the ID Token. * In Azure AD, even if the ID Token has the 
oid
claim, the Access Token might not include it unless the "Audience" (
aud
) of the token is the App Registration itself. * Fix: In your Java code, try changing the scope to include 
profile
. Azure AD only guarantees identity claims like 
oid
are included when the 
profile
scope is requested.
Copy code
java
    "&scope=openid+profile"
2. The Claim Name is actually a URI (Azure v1.0) If your Azure App Registration is configured for v1.0 tokens, the claim is not named 
oid
. It is a full URI. * Look at your token in 
<http://jwt.io|jwt.io>
. If you see a key like 
<http://schemas.microsoft.com/identity/claims/objectidentifier>
, that is the key you must use. * Fix: Change your StarRocks configuration to use the full string:
Copy code
sql
    SET PROPERTIES ("principal_field" = "<http://schemas.microsoft.com/identity/claims/objectidentifier>");
3. Use the 
sub
claim instead The 
sub
(Subject) claim is mandatory in the OpenID Connect standard and is guaranteed to be a top-level string in both ID and Access tokens from Azure. It is also an immutable, unique identifier for the user (similar to 
oid
). * Fix: Switch your 
principal_field
to 
sub
. It is much more reliable across different token versions and scopes.
Copy code
sql
    -- Update your Security Integration
    ALTER SECURITY INTEGRATION your_integration
    SET PROPERTIES ("principal_field" = "sub");

    -- Or update the user directly if not using integration
    -- Ensure the StarRocks username matches the 'sub' value in <http://jwt.io|jwt.io>
4. Check for nested claims StarRocks expects the 
principal_field
to be at the root of the JWT payload. If for some reason your identity provider has nested the claim (e.g., inside a 
user_info
object), StarRocks will not find it. Azure AD does not typically do this, but it's worth verifying that 
oid
is not inside another object in the JSON. Summary Checklist 1. Change Scope: Update your Java plugin to use 
&scope=openid+profile
. 2. Try `sub`: Change 
principal_field
to 
sub
in StarRocks and see if the error changes. 3. Match Username: Remember that the value of the 
oid
(the GUID) must match the StarRocks username exactly (e.g., 
CREATE USER '550e8400-e29b-41d4-a716-446655440000' ...
). References • administration/user_privs/authentication/oauth2_authentication.md • administration/user_privs/authentication/security_integration.md • administration/management/FE_configuration.md References • administration/management/FE_configuration.md • administration/user_privs/authentication/oauth2_authentication.md
2 Views
Open in Slack
PreviousNext
Powered by