Add Attributes to IdP Tokens and Profiles
Release department, location, and other directory fields so Skillhabit Attribute mappings can fill profiles.
What This Is For
Skillhabit Attribute mappings only work when your identity provider actually sends the value. This page shows how common IdPs put directory fields into:
| Skillhabit source type | Where the value comes from |
|---|---|
| OpenID Connect claim | ID token (and sometimes UserInfo) at login / JIT |
| Microsoft Entra property | Microsoft Graph user fields during Entra sync (and related Graph-backed paths) |
| SCIM attribute | SCIM user create/update payloads your IdP pushes |
After the IdP releases the field, map it in Skillhabit under Configure → Connections → Attribute mappings. Full Skillhabit-side steps: User Provisioning → Map Directory Attributes.
Who This Is For
Workspace administrators working with your identity / Entra / Okta / Auth0 admin. You need permission to change app claim configuration in the IdP—not only Skillhabit Configure.
Before You Start
- Create the Skillhabit Attributes you want to fill (Custom Attribute Fields).
- Decide the source type for each mapping (OIDC claim vs Entra Graph property vs SCIM path)—they are not interchangeable.
- Prefer short, stable claim or property names (for example
department,officeLocation). Avoid renaming claims later; remapping in Skillhabit is easier than breaking every token consumer. - After IdP changes, sign out and sign in again (OIDC) or run a sync / SCIM update so Skillhabit receives a fresh payload.
Microsoft Entra ID (Azure AD)
Entra is used in two different Skillhabit paths. Configure the path you actually use.
A) OpenID Connect / Microsoft login — optional claims on the token
Use this when Skillhabit maps an OpenID Connect claim at sign-in.
- In the Azure portal, open Microsoft Entra ID → App registrations → the app Skillhabit (or your broker) uses for OpenID Connect / Microsoft sign-in.
- Open Token configuration.
- Choose Add optional claim.
- Select token type ID (Skillhabit reads identity claims from the ID token / login profile path).
- Add the directory claims you need—for example
department,officeLocation, job title, or other optional claims Entra lists for your account type. - Save. If Entra prompts for Microsoft Graph permissions for that claim, grant admin consent.
- In Skillhabit, create a mapping with Source = OpenID Connect claim and External IdP Property Name = the claim name Entra emits (often the same short name, for example
department).
Custom / extension attributes in the ID token
- Prefer Enterprise applications → your app → Single sign-on → Attributes & Claims (SAML-style UI is also used for OIDC apps in many tenants) or a claims mapping policy on the service principal—follow your tenant’s standard for “emit extension attribute X as claim Y”.
- Emit a simple claim name Skillhabit can type into External IdP Property Name (for example
costCenter). Nested JSON paths are harder to support—prefer a flat string or string array. - Test with a fresh login. Confirm the claim appears in the ID token (Azure Token configuration, or a JWT decode of a test login) before debugging Skillhabit mappings.
B) Microsoft Entra directory sync — Graph properties (not token claims)
Use this when Skillhabit maps a Microsoft Entra property during Configure → Connections → Microsoft Entra ID sync.
Graph already exposes many profile fields without optional-claim setup—for example:
| Typical Graph property | Example use |
|---|---|
department | Department attribute |
officeLocation | Site / office |
jobTitle | Job title |
companyName | Company |
employeeId | Employee number |
onPremisesExtensionAttributes.extensionAttribute1 … extensionAttribute15 | Synced on-prem extension attributes |
In Skillhabit, set Source = Microsoft Entra property and External IdP Property Name to that Graph property path (exactly as above for extension attributes).
You do not need to put these on an ID token for Entra sync—sync reads Graph. You do still need optional claims (section A) if the same field must arrive on OIDC login for users who are not updated by sync.
Okta
Use this for OpenID Connect claim mappings when people sign in through Okta OIDC.
- In Okta Admin, open Security → API → Authorization Servers (or your custom authorization server used by the Skillhabit OIDC app).
- Open the authorization server → Claims.
- Add Claim:
- Name — the claim Skillhabit will map (for example
department). Use this exact string in Skillhabit External IdP Property Name. - Include in token type — ID Token (always / or matching your scopes).
- Value type — Expression or identity attribute (for example
user.department,user.costCenter, or a custom profile attribute).
- Name — the claim Skillhabit will map (for example
- Save and assign the claim so it is included for the Skillhabit client / scopes you use.
- Confirm the Okta OIDC app requests any scopes your claim requires.
- In Skillhabit: Source = OpenID Connect claim, External IdP Property Name = the claim Name from step 3.
App-level ID token claims (org authorization server)
Some orgs configure claims under the OIDC application → Sign On → OpenID Connect ID Token section instead of a custom authorization server. Same idea: define a claim name and map it from an Okta user profile attribute, then use that name in Skillhabit.
Multi-value attributes
If the Okta attribute is multi-valued, emit a JSON array of strings in the ID token when Skillhabit should fill a Multi Select attribute (Skillhabit replaces the whole set on each apply).
Auth0
Auth0 does not put arbitrary profile root fields on third-party ID tokens by default. Add custom claims with a namespaced identifier, then map that full claim name in Skillhabit.
- Create (or reuse) an Auth0 Action on the Login / Post Login flow.
- In the action, set claims on the ID token, for example:
exports.onExecutePostLogin = async (event, api) => {
const namespace = 'https://skillhabit.com';
if (event.user.department) {
api.idToken.setCustomClaim(`${namespace}/department`, event.user.department);
}
if (Array.isArray(event.user.groups)) {
api.idToken.setCustomClaim(`${namespace}/costCenters`, event.user.groups);
}
};- Deploy the Action and add it to the Login flow.
- Ensure the user profile (or an enrichment Action) actually populates
department/ custom metadata before the claim is set. - In Skillhabit: Source = OpenID Connect claim, External IdP Property Name = the full claim name, including namespace (for example
https://skillhabit.com/department).
Auth0 rejects non-namespaced custom claims on OIDC ID tokens—do not omit the namespace.
Generic OpenID Connect IdPs
For Ping, OneLogin, Keycloak, FusionAuth, AWS Cognito, and similar:
- Find the IdP setting that adds ID token claims or attribute statements for your Skillhabit OIDC client (names vary: Claims, Mappers, Attribute mapping, Token customization).
- Map a directory attribute → claim name.
- Include the claim in the ID token (not only the access token). Skillhabit attribute mapping for OIDC is driven by login identity claims.
- Prefer string or string-array values.
- In Skillhabit, type the claim name exactly as it appears in the ID token.
Minimum identity claims Skillhabit still needs for login itself (email, or preferred_username, or upn) are separate from attribute mappings—see SSO and Email Addresses.
SCIM Attribute Paths
When Skillhabit maps a SCIM attribute, the IdP must send that attribute on SCIM User create/update—not on an OIDC token.
Common patterns:
| What you want | Typical SCIM path to send / map |
|---|---|
| Department | urn:ietf:params:scim:schemas:extension:enterprise:2.0:User:department |
| Cost center | urn:ietf:params:scim:schemas:extension:enterprise:2.0:User:costCenter |
| Organization | urn:ietf:params:scim:schemas:extension:enterprise:2.0:User:organization |
| Custom extension | Your IdP’s extension URN + attribute name (tenant-specific) |
Steps (IdP side):
- Enable the Skillhabit SCIM connector and confirm core User provisioning works (User Provisioning → SCIM).
- In the IdP SCIM app, open attribute mappings / provisioning attributes.
- Map the directory field onto the SCIM attribute path Skillhabit expects.
- Push or reprovision a test user; confirm the attribute appears on the SCIM payload.
- In Skillhabit: Source = SCIM attribute, External IdP Property Name = that path (exact string your tenant uses).
Exact SCIM base URLs and which extension schemas Skillhabit accepts are workspace-specific—your Skillhabit contact confirms them when SCIM is enabled.
Verify End-to-End
- IdP — Decode a fresh ID token (OIDC) or inspect a SCIM/Graph payload and confirm the claim / property is present with the expected value.
- Skillhabit mapping — Configure → Connections → Attribute mappings points at that exact name/path and the right Source type.
- Apply — Sign in again (OIDC) or wait for / force Entra sync / trigger SCIM update.
- Profile — Open the user in Users & Groups; the Skillhabit attribute should update and stay locked when sourced from the IdP.
If the IdP never sends the field, Skillhabit cannot invent it—fix the IdP emission step first.
Related
- User Provisioning — Attribute mappings in Skillhabit
- SSO and Authentication
- SSO and Email Addresses
- Custom Attribute Fields
- Sync Users With SCIM