OIDC SSO - Auto provisionning - import table not created for userInfo

[mathieu_brule]

Hi !

I'm actually configuring a OIDC SSO for my customer : 

- the authentication is ok

- the user account I'm using is correctly connected to Service Now

I'm also configuring Autoprovisionning for my user, which is based on both ID Token and User info.

I have created a data source for ID Token provisionning, and a data source for user info provisionning.

-> The provisionning based on ID token works fine, it creates my user in sys_user table, if not exists

-> The provisionning based on user info doesn't work, because it doesn't create the import table automatically.

I've looked at on http outbound requests, I see the user info called, next to id token one.

I see an import set created on user info, but it fails, due to the lack of my import table...

Could you please help me to understand where I'm wrong ?

[Naveen20]

hi,

The ID Token data source auto-creates its import table because ServiceNow can parse the JWT structure directly at configuration time — it knows the claims schema upfront. The UserInfo data source works differently: it depends on an HTTP call to the UserInfo endpoint, and ServiceNow may not auto-generate the import table schema until it has a sample response to work from.

So the import set is created at runtime, but it has no table to write into — exactly the error you're seeing.

How to fix it

 options:

1 — Manually create the import set table. Go to your UserInfo data source record, note the import set table name it's referencing (something like u_oidc_userinfo_import or similar). Then manually create that table under System Import Sets > Administration > Import Set Tables (or just navigate to sys_import_set_table.do). Add columns that match the attributes your UserInfo endpoint returns — typically fields like sub, email, name, given_name, family_name, preferred_username, etc. Make sure column names match the JSON keys from your UserInfo response exactly.

2 — Use "Test Load" on the data source. Open your UserInfo data source, and if ServiceNow provides a "Test Load 20 Records" option, try running it. This sometimes triggers the platform to call the UserInfo endpoint, parse the response, and auto-generate the import table with the correct schema. However, this doesn't always work for OIDC-type data sources since they depend on an active SSO session.

After the import table exists, verify these pieces:

1. The data source record points to the correct import set table name.
2. A transform map exists that maps columns from that import table to sys_user fields (email → email, first_name → first_name, etc.) with the correct coalesce field (usually email or user_name).
3. The transform map is set to active and is associated with the correct import set table.

diagnostic: Check the outbound HTTP log to grab the raw JSON response from the UserInfo endpoint. That tells you exactly which column names your import table needs. You can find it under System Logs > Outbound HTTP Requests, filtering by the UserInfo URL.

[mathieu_brule]

Hi Naveen, 

Thanks for your feedback.

Actually, I have created manually my import table, but I understood that the issue was not really there, but when userInfo response was coming.

Indeed, I have the following error in the logs : 

Error while getting response from url = https://[......]/api/v2/userinfo: org.json.JSONException: A JSONObject text must begin with '{' at character 1 of eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCIsImtpZCI6IkhNdUtEUXdpVzZFSXdpdzJhNTlhdWxJTUhxYlF4bEVacm9raFcyRS1oaU0ifQ.eyJlbWFpbCI6ImNhdGhlcmluZS5zb3VkZWVAYWMtbmFudGVzLmZyIiwic3ViIjoiZDMxNjJmNmItNDc4ZC00NzcxLWFkMzAtNzc4MTk5YTdlYWQ0IiwiYXVkIjoiNzc1NGRjODMwNjE1NGIxYTQ5ZGRmODU1YjA3ODI2NTRhYmE0ZWZkNzE3OTRmNWI0ZmY3YTA5ZTc0OTFlOWUwZiIsImV4cCI6MTc3NTIzMzAwNywiaWF0IjoxNzc1MjI5NDA3LCJpc3MiOiJodHRwczovL2ZjYS5pbnRlZzAxLmRldi1hZ2VudGNvbm5lY3QuZnIvYXBpL3YyIn0.ECAhZOWeHyzIktI403DW-6sbbiilq31Umh56Xr4Jq1UNF5hrjzTn5E5A9kiz3CGfFGbcGps3Y5R-69MxxwtEZb7xw8xqdWEAlF3iOV2HwIYtKAXZLgiHHM0zL9DA2vFd2P1_VYHulJhCsBWkKEHiLQB-0xYfiB314GfNiBwm_LIRje3hXJOTVS7690Np4ha9bck28EMasUajuWj1evU09UuzgJMD3fHtDEbO-cQu_My1rjrQLO87wS0nttThZg-wN1IwT78158TxSDQmK-iHcUVuchtom9yZYGtZeV3YwcjqdeQAX7Yf89N1473pEuSprovx9CYgd9RmgIt17ZOXHuu_j0IC5uhnEzE4vCyHNGh6oFd2bwZImU5IQ5QIhWcYtHy6-Yf1Pl9JKIISWS1o-rlaR6i2U6ubyTPUFsaoO16nFUM0WrEyKxHAaUTsZE3zugTraAlNU3AF4iTi0_6ggIvzdD87rYTU7e4mqtQbRnZAtuu4v9mlOzjxWi6_KklBJGxzTkLUpCQtdESmV7KNu_X2VzBDku7Y2r8HIgYeRriC4J43-NFTpMjoCSRxAFl4rasvJqRnbCFnqdJVaetF9wodaOKc6AcoeMl_7k5imaSCrgjBhFyvVkVf6jQrxNOfuf9-9LDPx4-sE-J-U2AuU7hKEaPo3tS6dZhJ8jvx4vg: org.json.JSONTokener.syntaxError(JSONTokener.java:448)
org.json.JSONObject.<init>(JSONObject.java:184)

And in my outbound log, I have the following : 

I'm skeptikal that it's due to an error on the provider side, because we are not the only one who user this provider.

So where could be the issue ?

[Naveen20]

Your identity provider's UserInfo endpoint is returning a JWT (JSON Web Token) instead of plain JSON — and ServiceNow expects raw JSON.

Look at the response body in your error: eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCIs... — that's a base64url-encoded JWT header. If you decode it, the header is:

json

{"alg":"RS256","typ":"JWT","kid":"HMuKDQwiW6EIwiw2a59aulIMHqbQxlEZrokhW2E-hiM"}

And the payload contains:

json

{
  "email": "catherine.soudee@ac-nantes.fr",
  "sub": "d3162f6b-478d-4771-ad30-778199a7ead4",
  "aud": "7754dc83...",
  "exp": 1775233007,
  "iat": 1775229407,
  "iss": "https://fca.integ01.dev-agentconnect.fr/api/v2"
}

So the data is there — ServiceNow just can't read it because it tries to parse the raw string as JSON and chokes on the e in eyJ... instead of finding {.

Why this happens

The OIDC specification (RFC 7231 / OpenID Connect Core Section 5.3.2) actually allows the UserInfo endpoint to return either plain JSON or a signed JWT. Your provider (AgentConnect) returns a signed JWT. ServiceNow's out-of-box OIDC UserInfo handler only expects plain JSON, so it fails.

 it's a compatibility gap.

How to fix 

Option 1 — Skip UserInfo provisioning entirely (simplest). Since the JWT payload from UserInfo contains email and sub, check whether your ID Token already carries all the claims you need. If you request the right scopes (like email, profile) from AgentConnect, the ID Token may already include everything. Then you only need the ID Token data source and can disable UserInfo provisioning altogether.

Option 2 — Use a custom AttributeDecoder / Script. In your OIDC provider configuration, ServiceNow allows you to define custom scripts to process responses. You can intercept the UserInfo response and decode the JWT before it hits the JSON parser. In the OIDC provider record, look for a field like User Info Script or a script-based hook. The logic would be something like:

javascript

// Split the JWT and decode the payload (middle segment)
var parts = userInfoResponse.split('.');
if (parts.length === 3) {
    var payload = GlideStringUtil.base64Decode(parts[1]);
    // payload is now the plain JSON string
    var jsonObj = new JSON().decode(payload);
    // map claims to user attributes
}

Option 3 — Check for a system property. Depending on your ServiceNow version, there may be a system property like glide.authenticate.sso.oidc.userinfo.jwt_response or similar that tells the platform to expect a JWT from UserInfo. Search sys_properties for keywords like oidc, userinfo, and jwt.

My recommendation: Go with Option 1 if your ID Token already has all the user attributes you need for provisioning. It's the cleanest path.

[mathieu_brule]

Hi Naveen, 

Thanks a lot for your answer. 

In what version the property glide.authenticate.sso.oidc.userinfo.jwt_response is available please ?

Indeed, I can't have my user information in my ID Token, even the email is not sent in this one, it's only available in user info claims...

So I like the property solution, but as a workaround, I could work on customization on the script you mentionned.