Relying Party Trust Identifier

When configuring SharePoint for claims-based authentication or authorization, Microsoft SharePoint typically connects to an identity provider such as Okta to retrieve user attributes as claims. To realize all the benefits of claims in an enterprise environment, administrators need to ensure that SharePoint trusts the claims it receives. This means configuring SharePoint to connect to a Trusted Identity Provider such as Okta. Okta retrieves user attributes from Active DirectoryActive Directory (AD) is a directory service that Microsoft developed for the Windows domain networks. It is included in most Windows Server operating systems as a set of processes and services. Initially, Active Directory was only in charge of centralized domain management. (or another LDAPLightweight Directory Access Protocol (LDAP) is a lightweight client-server protocol for accessing directory services, specifically X.500-based directory services. LDAP runs over TCP/IP or other connection oriented transfer services. directory or data store), wraps them in a SAMLAn acronym for Security Assertion Markup Language, SAML is an XML-based standard for exchanging authentication and authorization data between an identity provider (IdP) and a service provider (SP). The SAML standard addresses issues unique to the single sign-on (SSO) solution, and defines three roles: the end user, the IdP, and the SP. Here's how SAML works through Okta: SP-initiated flow: the end user requests (principally through a browser) a service from the SP. The SP requests and obtains an identity assertion from the IdP (in this case, Okta). On the basis of this assertion, the SP can decide whether or not to authorize or authenticate the service for the end user. IdP-initiated flow: with Okta as the IdP, an end user goes to the Okta browser and clicks on an app, sending a SAMLResponse to the configured SP. A session is established with the SP, and the end user is authenticated. token, digitally signs that token, and returns it to the calling application, which is part of a realm. The realm is associated with a web application. It is how Okta maps the sign-in request to the relying party trusts.

Okta People Picker

Okta offers a SharePoint People Picker to find and select native Okta users, groupsGroups allow you to organize your end users and the apps they can access. Assigning apps to large sets of end users is made easier with groups., and claims when a site, list, or library owner assigns permissions in Microsoft SharePoint. SharePoint integrates with Okta using the Okta API. The Okta API enables administrators to manage permissions for native Okta users and groups in SharePoint. Administrators can define access rules to the SharePoint site and also filter and restrict the results that are displayed when a user searches for a user, group, or claim. These settings are applied to every site within the site collection. For example, administrators can grant access to users who match a certain email address or who are part of an AD or Okta group.

For more information, refer to the following Microsoft docs:

Claims to Windows Token Service (C2WTS)

Enterprise SharePoint deployments can use back-end components that depend on Windows AuthenticationAuthentication is distinct from authorization, which is the process of giving individuals access to system objects based on their identity. Authentication merely ensures that the individual is who he or she claims to be, but says nothing about the access rights of the individual. Authentication methods and protocols include direct auth, delegated auth, SAML, SWA, WS-Fed, and OpenID Connect. and require protocol transition from claims-based authentication Okta SSOAn acronym for single sign-on. In a SSO system, a user logs in once to the system and can access multiple systems without being prompted to sign in for each one. Okta is a cloud-based SSO platform that allows users to enter one name and password to access multiple applications. Users can access all of their web applications, both behind the firewall and in the cloud, with a single sign in. Okta provides a seamless experience across PCs, laptops, tablets, and smartphones. to Windows Authentication. Okta SharePoint solution enables this protocol transition using KerberosKerberos is a computer-network authentication protocol that works on the basis of tickets to allow nodes communicating over a non-secure network to prove their identity to one another in a secure manner. Constrained Delegation and S4U.

For more information on C2WTS, refer to the following Microsoft docs:

SharePoint People Picker 2.x.00

Okta SharePoint Claim Provider integration uses email or username as the claim value to uniquely identify a user. It allows you to select from two search scopes to query users from: OKTA and APPAn abbreviation of application. Essentially, it is a web-based site used to perform any number of specific tasks, and requires authentication from end users by signing in..


If OKTA is selected, People Picker queries for Okta users and creates People Picker entity claim values in SharePoint from their Okta user profiles.

  • If the identifier selected is Email, then the claim type Email will be populated from the Okta user’s profile email.
  • If the identifier selected is UserName, then the claim type Username will be populated from the Okta user’s profile login.
  • When the search scopeA scope is an indication by the client that it wants to access some resource. is OKTA, users can search on firstName, lastName, and email of the user's Okta user profile.


If APP is selected, People Picker queries for app users in specified app instance and creates People Picker entity claim values in SharePoint from their App user profiles.



When UserSearchScope is set to APP, search for groups is not performed at app level.

  • If the identifier selected is Email, then the claim type Email will be populated from App user’s profile email.
  • If the identifier selected is UserName, then the claim type Username will be populated from App user’s profile username. AppUser.UserName field mapping can be used to customize the Username claim type with a unique and immutable identifier.
  • When the search scope is APP, users can search on firstName, lastName, email, and userName of the user's App user profile.

Important to Know

  • When you rename email addresses based on name changes such as marriage or divorce, the identifier becomes not stable or immutable. Since the email address is persisted in SharePoint as the claim value for an authorization rule, it is possible that a different user with the previous email address would get unintended access to the resource.
  • Okta Claim Provider does not restrict which external users can be selected in an Okta orgThe Okta container that represents a real-world organization. and allows wild-card matches for any prefix match of email, firstName, or lastName profile attributes. It is possible to grant a user access to a resource but the user is not assigned the SharePoint application in Okta. Filtering for Active Directory domains can't be used if the users are Okta-mastered.
  • If you already have a previous version of People Picker installed, completely uninstall it and then install the new People Picker.
  • If you want to change the UniqueUserIdentifierClaimType for the SharePoint farm, first remove Okta Authentication by running the PowerShell command remove­sptrustedtokenissuer, and then reconfigure the Okta trusted token issuer with the new claim type.