OIDC in SharePoint Server Subscription Edition: Where It Fits and Why It Matters

Authentication in SharePoint Server has gone through a lot of changes over the years. Most of us started with Windows authentication using NTLM or Kerberos, moved through Claims authentication, added SAML-based trusted identity providers, and then started integrating on-premises SharePoint with modern identity platforms.

SharePoint Server Subscription Edition adds another option to that list: OpenID Connect, or OIDC.

OIDC gives SharePoint a standards-based way to authenticate users through an external identity provider. That provider might be Microsoft Entra ID, AD FS, or another platform capable of meeting SharePoint’s OIDC requirements. Microsoft documents configurations for Entra ID and AD FS, plus options for establishing trust manually using signing certificates or RSA public keys.

For organizations still running SharePoint on-premises, this matters. OIDC lets you modernize the authentication boundary without moving SharePoint into Microsoft 365, and it brings SharePoint closer to the identity architecture already used by modern web apps, APIs, and cloud services.

It’s tempting to look at OIDC, OAuth, SAML, NTLM, and Kerberos as competing versions of the same thing. They aren’t. They solve different problems and operate at different parts of the authentication and authorization process. Understanding those differences first makes the SharePoint configuration much easier to reason about.

What OIDC Actually Is

OIDC is an identity protocol built on top of OAuth 2.0. That distinction matters because OAuth and OIDC get used interchangeably far too often.

OAuth 2.0 is primarily an authorization framework, not an authentication protocol. It lets an application obtain permission to access a resource on behalf of a user or another application. OIDC adds an identity layer on top of that. It lets an application determine who authenticated, typically through an ID token containing claims about the authenticated identity.

For SharePoint, that means an external identity provider authenticates the user and issues an ID token. SharePoint validates that token, processes its claims, and builds a SharePoint Claims identity from it.

SharePoint isn’t asking the identity provider whether a user should have access to a site, library, or list. The identity provider establishes who the user is. SharePoint still makes every authorization decision on its own, using its own permissions model. Keep that authentication-vs-authorization line in mind because it comes up repeatedly throughout the configuration.

Why OIDC Matters for SPSE

Configuring OIDC doesn’t turn SharePoint into a cloud service. It’s still on-premises, with web applications, zones, Alternate Access Mappings, service applications, content databases, and everything else you already manage. What changes is the authentication boundary.

Instead of SharePoint authenticating users directly through Windows authentication, or relying on the older SAML federation model, it can redirect users to a modern OIDC identity provider. That provider decides how the user proves who they are, whether that means MFA, passwordless authentication, FIDO2, device-based controls, risk-based checks, or something else. SharePoint doesn’t need to understand those mechanics. It trusts the provider and validates the token that comes back.

Microsoft Entra ID is the obvious example, since many SharePoint Server environments already use Microsoft 365. But OIDC support in SPSE isn’t an Entra-only feature. Microsoft documents AD FS as an identity provider too, and SharePoint can establish trust with other compatible OIDC providers. That makes OIDC useful for hybrid identity architectures, external users, partner identities, or environments that no longer revolve entirely around Windows authentication.

OIDC Doesn’t Replace SharePoint Claims

OIDC changes how identity and claims reach SharePoint. It doesn’t replace the Claims architecture underneath it.

The identity provider authenticates the user and issues an ID token containing claims. SharePoint validates that token and maps selected incoming claims into claim types it understands, which is why New-SPClaimTypeMapping is still part of the configuration:

$emailClaimMap = New-SPClaimTypeMapping `
    -IncomingClaimType `
    "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress" `
    -IncomingClaimTypeDisplayName "Email" `
    -SameAsIncoming

That mapping later becomes the identifier claim when you create the trusted identity provider. Conceptually, the process looks like this:

The protocol changed. The underlying Claims architecture didn’t. Sites, groups, permission levels, securable objects, and Claims identities all keep working the way you already expect. OIDC just gives you another way to get identity into that system.

How OIDC Compares to What You Already Know

Before getting into the SharePoint configuration, it helps to put OIDC alongside the authentication technologies most SharePoint administrators already know.

• NTLM ties authentication directly to Windows credentials through challenge-response. It’s still fine internally, but it doesn’t give you the federation capabilities modern identity platforms expect.
• Kerberos is also Windows authentication, but it is ticket-based and built around Active Directory and the Key Distribution Center. It supports delegation, which matters for some SharePoint architectures, but it also involves SPNs, service identities, and careful infrastructure planning. Kerberos establishes that Active Directory authenticated a Windows identity. OIDC establishes that a trusted identity provider authenticated an identity and issued a signed token. Those are completely different trust boundaries, and OIDC becomes useful when the identity doesn’t need to originate from the same Active Directory domain hosting SharePoint.
• SAML is the closest comparison because SharePoint has supported SAML trusted identity providers for years. Both SAML and OIDC federate authentication through an external provider. The difference is in the protocol and token format: SAML is XML-based and uses assertions, while OIDC runs on OAuth 2.0 and typically uses JWTs. SAML isn’t obsolete just because OIDC exists, and plenty of SharePoint environments run it perfectly well. However, OIDC aligns more naturally with modern identity platforms, and it is what I would strongly consider for a new federated authentication design.
• OAuth 2.0 is primarily an authorization framework rather than an authentication protocol. It is concerned with whether an application can access a resource, rather than establishing the identity of the person using that application. An access token targets a resource or API. An ID token targets the client application and describes the authenticated identity. OIDC builds on OAuth 2.0, but they solve different problems. For SharePoint OIDC authentication, the ID token is what matters because SharePoint needs to establish who is attempting to access the web application.

Understanding the ID Token

OIDC ID tokens are typically JSON Web Tokens, or JWTs. Depending on the provider and configuration, you might see claims such as:

• iss – Issuer: Identifies the identity provider that issued the token. SharePoint uses this to confirm that the token came from the provider it has been configured to trust.
• aud – Audience: Identifies the application the token was intended for. SharePoint validates this against the client identifier configured on the trusted identity token issuer.
• sub – Subject: Provides a unique identifier for the authenticated user within the context of that identity provider. Unlike values such as a display name, it is intended to consistently identify the subject of the token.
• email – Email Address: Contains the user’s email address when the identity provider is configured to include it. This can be mapped into SharePoint and can also be used as the IdentifierClaim, as shown in Microsoft’s Entra ID example.
• name – Display Name: Contains a human-readable name for the authenticated user. This is useful for displaying information about the user but generally isn’t something I would rely on as a unique identity.
• roles – Roles: Contains application roles assigned to the user or other authenticated principal. These can be mapped into SharePoint claims and potentially used when designing role-based authorization.
• groups – Groups: Can contain information about group memberships associated with the user. Group claims can be useful for authorization, but they need careful planning because large group memberships can affect what is returned in the token.

Two of those matter particularly when establishing the SharePoint trust. iss identifies who issued the token, so SharePoint needs to know that it came from an identity provider it trusts. aud identifies the intended audience, and SharePoint validates that value against the client identifier configured on the trusted token issuer.

Don’t assume every claim available in the identity provider automatically appears in the ID token. The provider’s application configuration, scopes, token configuration, and claim rules determine what is actually returned. Likewise, don’t assume SharePoint needs every claim it receives. Only map claims that serve a genuine purpose in the SharePoint identity or authorization model.

The SPTrustedIdentityTokenIssuer

At the center of the SharePoint-side configuration is an object familiar to anyone who has configured SAML authentication: SPTrustedIdentityTokenIssuer, created using New-SPTrustedIdentityTokenIssuer.

Despite the name, this is the object SharePoint uses to establish trust with the external OIDC provider. It defines information such as the provider name, issuer information, client identifier, claim mappings, identifier claim, signing information, authorization endpoint, metadata endpoint where applicable, and sign-out behavior.

Creating an application registration in Entra ID doesn’t automatically make SharePoint trust it. Creating the SPTrustedIdentityTokenIssuer doesn’t automatically configure the identity provider either. Both sides need to agree on the application, endpoints, identifiers, token signing, redirect URI, and claims.

Once you strip away the parameter list, this cmdlet is really answering five questions:

• Who issued this identity? This is discovered through metadata or supplied using an explicit issuer.
• Was the token intended for this SharePoint application? This is where the client identifier and the token’s audience come together.
• Can SharePoint trust the signature? This is established through signing certificates, RSA public keys, or metadata-based signing information.
• What identifies the user? This is controlled through the identifier claim and claim mappings.
• Where does SharePoint send the browser to sign in and out? These are the authorization and sign-out endpoints, either supplied directly or discovered through metadata.

Everything else in the configuration is really just filling in the answers to those five questions.

The Identity Provider Side of the Trust

Before creating the SharePoint trust, the identity provider needs to know about SharePoint as well. This is easy to overlook because most of the SharePoint documentation naturally concentrates on the farm-side PowerShell.

With Microsoft Entra ID, SharePoint is represented by an application registration. That registration gives us the application, or client, ID that will later become the DefaultClientIdentifier on the SharePoint trusted identity token issuer.

The application registration also needs a redirect URI that points authentication responses back to SharePoint. Microsoft’s documented configuration uses the SharePoint /_trust/ endpoint:

https://<SharePointSite>/_trust/

For example:

https://portal.contoso.com/_trust/

This URL matters. The identity provider will only redirect the authentication response to a URI it recognizes for the application, so the value configured at the provider needs to match the SharePoint URL being used for OIDC.

The application registration is also where you start thinking about the token SharePoint will eventually receive. Which claims need to be present? Which identity will SharePoint use? Are roles or other application-specific claims required? These decisions need to line up with the SPClaimTypeMapping objects created later in SharePoint.

Entra ID is simply a useful example here. With AD FS or another OIDC provider, the terminology and administrative interface may be different, but the same basic relationship exists. The identity provider needs to know about SharePoint as a relying client, and SharePoint needs to know which provider it trusts.

The client identifier is what ties those two configurations together.

Choosing the Identifier Claim

The IdentifierClaim parameter decides which incoming claim uniquely identifies the user. Microsoft’s Entra ID example uses the email claim:

$emailClaimMap = New-SPClaimTypeMapping `
    -IncomingClaimType `
    "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress" `
    -IncomingClaimTypeDisplayName "Email" `
    -SameAsIncoming

The mapping can then be configured as the identifier:

-IdentifierClaim $emailClaimMap.InputClaimType

This isn’t just another attribute. It is fundamental to how SharePoint represents the user within Claims authentication.

Decide this early and be cautious about changing it later. The value needs to be unique, stable, and consistently returned by the identity provider. If it changes, SharePoint can end up treating the same person as a completely different Claims identity, which can break permissions already assigned to that user.

Email works well for documentation purposes and is what Microsoft uses in its Entra example, but that doesn’t automatically make it the correct choice for every environment. Think about the identity lifecycle behind whichever value you select, including whether that value can change when someone changes their name, domain, organization, or employment status.

Once the identifier claim is established, the next step is deciding what additional claims SharePoint needs, configuring the OIDC nonce certificate, and then creating the actual trust using metadata, certificates, or RSA public keys.

Mapping Additional Claims

The identifier claim is only the beginning. An ID token may also contain information such as the user’s email address, display name, roles, groups, or other attributes that could be useful within SharePoint.

Additional claims are mapped using more SPClaimTypeMapping objects. For example, a role claim could be mapped like this:

$roleClaimMap = New-SPClaimTypeMapping `
    -IncomingClaimType `
    "http://schemas.microsoft.com/ws/2008/06/identity/claims/role" `
    -IncomingClaimTypeDisplayName "Role" `
    -SameAsIncoming

The mappings can then be collected together before creating the trusted identity token issuer:

$claimMappings = @(
    $emailClaimMap,
    $roleClaimMap
)

The important thing here is to validate what the identity provider actually sends rather than designing the SharePoint configuration around assumptions. Directory attributes do not automatically appear in every ID token. The provider’s application configuration, scopes, token configuration, and claim rules determine what SharePoint actually receives.

Be especially careful with group claims. It is tempting to send every group a user belongs to and effectively recreate the entire directory authorization model inside the token, but large group memberships can introduce problems around token size, claims processing, and identity resolution. Add claims because SharePoint genuinely needs them, not simply because the identity provider can send them.

From SharePoint Server Subscription Edition Version 24H2, Set-SPTrustedIdentityTokenIssuer supports the -ClaimsMappings parameter, allowing the claim mappings on an existing trusted issuer to be updated:

Set-SPTrustedIdentityTokenIssuer `
    -Identity $providerName `
    -ClaimsMappings $claimMappings `
    -IsOpenIDConnect

That provides more flexibility than having the original claim mappings effectively locked into the trust created at the beginning of the deployment.

The OIDC Nonce Certificate

Before OIDC authentication works, SharePoint also needs a nonce cookie certificate. A nonce, or “number used once,” helps SharePoint associate the authentication response it receives with the authentication request it originally created. It is an important part of protecting the authentication flow and needs to be configured at the SharePoint farm level.

How the certificate is managed depends on the SharePoint Server Subscription Edition build. From Version 24H1, OIDC integrates with SharePoint Certificate Management, allowing the farm to manage the nonce certificate centrally rather than requiring administrators to manually install and permission the certificate on every SharePoint server.

For example, a self-signed certificate can be created:

$cert = New-SelfSignedCertificate `
    -CertStoreLocation Cert:\LocalMachine\My `
    -Provider 'Microsoft Enhanced RSA and AES Cryptographic Provider' `
    -Subject "CN=SharePoint Cookie Cert"

Export the certificate:

$certPath = "C:\Certs\SharePointNonce.pfx"
$certPassword = ConvertTo-SecureString `
    -String "<StrongPassword>" `
    -Force `
    -AsPlainText
Export-PfxCertificate `
    -Cert $cert `
    -FilePath $certPath `
    -Password $certPassword

Then import it into SharePoint Certificate Management:

$nonceCert = Import-SPCertificate `
    -Path $certPath `
    -Password $certPassword `
    -Store "EndEntity" `
    -Exportable:$true

Finally, assign the certificate as the farm’s nonce certificate:

$farm = Get-SPFarm
$farm.UpdateNonceCertificate(
    $nonceCert,
    $true
)

This step is easy to overlook if you approach the deployment purely from the identity-provider side. The application registration can be correct, the claims can match, and the issuer can be configured perfectly, but OIDC authentication can still fail if the SharePoint prerequisites are not in place.

On builds prior to Version 24H1, the nonce certificate has to be managed manually. It needs to be installed with its private key on every SharePoint server, and the web application pool account needs access to that private key. For a new implementation, I would much rather patch the farm to a current build and use SharePoint Certificate Management than deliberately build around that older manual process.

Creating the Trust: Metadata, Manual, or RSA

Once the claims and nonce certificate are ready, we can create the actual OIDC trust.

There are several ways of doing this depending on what the identity provider supports. The underlying objective is the same in every case: SharePoint needs enough information to validate the provider, the token, and its cryptographic signature.

Metadata-Based Configuration

If the provider exposes compatible OIDC metadata, this is generally the cleanest option. Instead of manually entering every endpoint and maintaining the provider’s signing information yourself, SharePoint can use the provider’s metadata endpoint.

For Microsoft Entra ID, the endpoint follows this pattern:

https://login.microsoftonline.com/<TenantID>/.well-known/openid-configuration

Entra ID exposes multiple OIDC discovery endpoints, but Microsoft’s SharePoint configuration documentation specifies the v1.0 metadata endpoint for this configuration.

The SharePoint configuration could therefore look like this:

$providerName = "EntraOIDC"
$tenantId = "<Tenant-ID>"
$clientIdentifier = "<Application-Client-ID>"
$metadataEndpoint = `
"https://login.microsoftonline.com/$tenantId/.well-known/openid-configuration"
$emailClaimMap = New-SPClaimTypeMapping `
    -IncomingClaimType `
    "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress" `
    -IncomingClaimTypeDisplayName "Email" `
    -SameAsIncoming
$oidcTrust = New-SPTrustedIdentityTokenIssuer `
    -Name $providerName `
    -Description "Microsoft Entra ID OIDC Provider" `
    -ClaimsMappings $emailClaimMap `
    -IdentifierClaim $emailClaimMap.InputClaimType `
    -DefaultClientIdentifier $clientIdentifier `
    -MetadataEndPoint $metadataEndpoint `
    -Scope "openid profile"

There are several important values here.

DefaultClientIdentifier is the client identifier SharePoint uses when validating the token audience. This should correspond to the application/client ID from the identity-provider configuration.

MetadataEndPoint tells SharePoint where the provider’s OIDC configuration can be discovered.

ClaimsMappings tells SharePoint which incoming claims it understands, while IdentifierClaim identifies the claim that represents the user.

Finally, Scope defines the OIDC scopes requested as part of the authentication flow.

The metadata approach also has an important operational benefit on current SharePoint Server Subscription Edition builds. Version 24H2 introduced the RefreshMetadataFeed timer job for OIDC trusted identity token issuers configured with metadata endpoints. The job refreshes information obtained through the metadata feed, including signing certificates, issuer information, and endpoints. You can inspect the timer job using:

Get-SPTimerJob RefreshMetadataFeed

Its schedule can also be changed if required:

Get-SPTimerJob RefreshMetadataFeed |
    Set-SPTimerJob -Schedule "weekly at sat 5:00"

If an OIDC trusted identity token issuer was created before this functionality was available, setting the metadata endpoint on the existing issuer enables the metadata refresh behavior:

Set-SPTrustedIdentityTokenIssuer `
    -Identity $providerName `
    -MetadataEndPoint $metadataEndpoint

Without metadata-based configuration, signing certificate rotation can require the SharePoint trust to be updated manually. That operational overhead is another good reason to use metadata discovery where both the identity provider and the SharePoint configuration support it.

Manual Configuration

Metadata discovery is not always available or appropriate. SharePoint can also be configured explicitly by supplying the issuer, authorization endpoint, sign-out endpoint, signing certificates, client identifier, and claim mappings yourself. This makes the configuration longer, but it also makes each component of the trust very visible. For example:

$providerName = "EntraOIDC"
$tenantId = "<Tenant-ID>"
$clientIdentifier = "<Application-Client-ID>"
$authorizationEndpoint = `
    "https://login.microsoftonline.com/$tenantId/oauth2/authorize"
$registeredIssuer = `
    "https://sts.windows.net/$tenantId/"
$signOutUrl = `
    "https://login.microsoftonline.com/$tenantId/oauth2/logout"
$emailClaimMap = New-SPClaimTypeMapping `
    -IncomingClaimType `
    "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress" `
    -IncomingClaimTypeDisplayName "Email" `
    -SameAsIncoming

You then need the provider’s signing certificates. When working from JWKS information containing x5c certificate values, those Base64-encoded certificate strings can be converted into certificate objects:

$encodedCertStrings = @(
    "<x5c-certificate-string-1>",
    "<x5c-certificate-string-2>"
)
$certificates = @()
foreach ($encodedCertString in $encodedCertStrings) {
    $certificates += New-Object `
        System.Security.Cryptography.X509Certificates.X509Certificate2 `
        @(,[System.Convert]::FromBase64String($encodedCertString))
}

The trusted identity token issuer can then be created explicitly:

$oidcTrust = New-SPTrustedIdentityTokenIssuer `
    -Name $providerName `
    -Description "Microsoft Entra ID OIDC Provider" `
    -ImportTrustCertificate $certificates `
    -ClaimsMappings $emailClaimMap `
    -IdentifierClaim $emailClaimMap.InputClaimType `
    -RegisteredIssuerName $registeredIssuer `
    -AuthorizationEndPointUri $authorizationEndpoint `
    -SignOutUrl $signOutUrl `
    -DefaultClientIdentifier $clientIdentifier `
    -Scope "openid profile"

The same principles apply regardless of which identity provider is being used. SharePoint needs to know where authentication happens, who issued the token, whether the token was intended for this application, how the signature should be validated, and which claim identifies the user.

Manual configuration simply means you are supplying those answers yourself rather than allowing OIDC metadata to supply them.

RSA Public Keys

SharePoint Server Subscription Edition Version 24H2 added another useful option for OIDC providers that expose RSA modulus and exponent values directly rather than providing x5c certificates.

If the provider exposes compatible metadata, SharePoint can detect the appropriate key information automatically. For a manual configuration, the RSA public key can be supplied using the -PublicKey parameter.

The public key is represented in XML:

$publicKeyXml = @"
<RSAKeyValue>
    <Modulus>$modulus</Modulus>
    <Exponent>$exponent</Exponent>
</RSAKeyValue>
"@

That value can then be used when creating the trust:

$oidcTrust = New-SPTrustedIdentityTokenIssuer `
    -Name "OIDC-RSA" `
    -Description "OIDC Provider using RSA public key" `
    -PublicKey $publicKeyXml `
    -ClaimsMappings $emailClaimMap `
    -IdentifierClaim $emailClaimMap.InputClaimType `
    -DefaultClientIdentifier $clientIdentifier `
    -RegisteredIssuerName $registeredIssuer `
    -AuthorizationEndPointUri $authorizationEndpoint `
    -SignOutUrl $signOutUrl `
    -Scope "openid profile"

This broadens the range of OIDC providers SharePoint can work with. The provider does not necessarily need to publish x5c certificate information as long as SharePoint can obtain the RSA public key required to validate the JWT signature.

Multiple Client Identifiers

Another capability added in Version 24H2 is support for scoped client identifiers alongside the DefaultClientIdentifier.

These can be configured using -ScopedClientIdentifier:

Set-SPTrustedIdentityTokenIssuer `
    -Identity $providerName `
    -ScopedClientIdentifier $scopedClientIdentifiers `
    -IsOpenIDConnect

This can be useful in more complex architectures where different client identifiers need to be associated with different URI scopes rather than routing everything through a single default client identifier.

For a first OIDC deployment, I would concentrate on understanding DefaultClientIdentifier first. Scoped client identifiers provide additional flexibility when the architecture actually requires them rather than something that needs to be introduced simply because the capability exists.

Creating the Authentication Provider

Creating the trusted identity token issuer establishes the trust between SharePoint and the OIDC identity provider. It does not automatically enable that trust for a SharePoint web application. For that, we need an SPAuthenticationProvider.

Retrieve the trusted issuer:

$spTrust = Get-SPTrustedIdentityTokenIssuer `
    -Identity $providerName

Then create the authentication provider:

$oidcAuthenticationProvider = `
    New-SPAuthenticationProvider `
        -TrustedIdentityTokenIssuer $spTrust

The relationship between the objects is straightforward:

SPTrustedIdentityTokenIssuer
Defines the external identity trust
        ↓
SPAuthenticationProvider
Makes that trust available as an authentication provider
        ↓
SharePoint Web Application / Zone
Determines where the provider can actually be used

This distinction is important because a trusted identity token issuer exists at the farm level. Creating it does not mean every web application in the farm suddenly starts using OIDC.

The next decision is therefore where OIDC belongs within the SharePoint web application architecture. Microsoft documents both configuring OIDC alongside Windows authentication and extending an existing web application into another zone. That decision also needs to account for one particularly important SharePoint requirement: the Search crawler still needs Windows authentication available in the Default zone.

Planning the Web Application Architecture

Once the trust and authentication provider exist, the next question is where OIDC should actually be used. Microsoft documents two approaches. You can configure a web application with both Windows authentication and OIDC available in the Default zone, or you can extend an existing web application into another zone and configure that zone for OIDC.

The right approach depends on the environment, but one SharePoint requirement needs to be considered from the beginning:

the SharePoint Search crawler requires Windows authentication in the Default zone.

That doesn’t mean OIDC is the wrong choice. It means not every authentication path in the farm needs to use OIDC.

For an existing SharePoint environment, I generally like the idea of keeping the Windows-authenticated Default zone intact and extending the web application for OIDC. It provides a clean separation between the authentication mechanisms while allowing Search and other internal SharePoint components to continue using the authentication path they expect. Conceptually, that might look like this:

Users can access the OIDC-enabled URL while SharePoint Search continues crawling through the Windows-authenticated Default zone. That is a good example of why OIDC should be treated as part of the SharePoint architecture rather than simply an authentication setting.

Extending the Web Application for OIDC

If the existing web application uses Windows authentication in the Default zone, we can extend it into another zone and assign the OIDC authentication provider created earlier.

For example:

$webApp = Get-SPWebApplication `
    -Identity "http://portal.contoso.local"
$spTrust = Get-SPTrustedIdentityTokenIssuer `
    -Identity $providerName
$oidcAuthenticationProvider = `
    New-SPAuthenticationProvider `
        -TrustedIdentityTokenIssuer $spTrust
New-SPWebApplicationExtension `
    -Identity $webApp `
    -Name "Portal - OIDC" `
    -Zone Internet `
    -URL "https://portal.contoso.com" `
    -Port 443 `
    -HostHeader "portal.contoso.com" `
    -AuthenticationProvider $oidcAuthenticationProvider `
    -SecureSocketsLayer

The exact command will depend on your web application, certificate configuration, host header, and zone design, but the important part is the relationship between the existing web application and the OIDC-enabled extension. The two URLs can provide different authentication paths while accessing the same SharePoint content.

HTTPS Is Required

The SharePoint URL used for OIDC needs to use HTTPS. That means the authentication design also needs to include DNS and certificate planning. The certificate presented for the site needs to be valid for that hostname and trusted by the clients accessing SharePoint.

This URL also needs to line up with the redirect URI configured at the identity provider:

https://portal.contoso.com/_trust/

A mismatch here can cause authentication failures even when the OIDC trust itself is configured correctly. This is why I would decide on the final SharePoint URL before creating the identity-provider application rather than building the application registration around a temporary URL and changing everything later.

Alternate Access Mappings Still Matter

OIDC does not remove SharePoint’s Alternate Access Mapping architecture. If users access:

https://portal.contoso.com

SharePoint still needs to understand that URL within the appropriate zone.

The same URL needs to line up across:

• DNS.
• TLS certificates.
• SharePoint Alternate Access Mappings.
• The SharePoint web application or extension.
• The redirect URI configured at the identity provider.

These components are easy to treat as separate configuration tasks, but from an OIDC authentication perspective they are all part of the same path.

If the identity provider returns the browser to a URL that SharePoint does not expect, or the redirect URI differs from the registered application configuration, authentication can fail before claim mapping even becomes relevant.

Testing the Authentication Flow

Once the web application is configured, test the complete flow using a dedicated test account before introducing OIDC to a larger user population. The expected sequence should look something like this:

Don’t stop testing because the SharePoint home page appears. Successful authentication proves only one part of the configuration.

Check the Claims identity created for the user. Add that identity to a SharePoint group and confirm the permissions work. Remove it and confirm access disappears. Test users who should have different permissions and at least one user who should have no access at all.

If roles or groups are being returned as claims, test those independently as well. Don’t assume group-based authorization works simply because an individual user can sign in.

People Picker Needs Planning

Authentication working correctly does not necessarily mean People Picker will provide the experience you expect. This becomes particularly important with OIDC because SharePoint needs a way to resolve identities when administrators and site owners grant permissions. A user successfully authenticating proves that SharePoint can accept their token. It does not automatically mean a site owner can type that person’s name into People Picker and reliably find the correct Claims identity.

If you are using additional role or group claims, identity resolution becomes even more important.

For a small environment where administrators control permissions directly, this may be manageable. For an environment with hundreds of site owners who regularly grant access themselves, People Picker becomes part of the authentication design rather than something to look at afterwards.

The deployment therefore needs to answer two different questions:

• Can the user authenticate?
• Can SharePoint administrators and site owners reliably find the correct identity when granting access?

Both need to work before the implementation is really finished.

Search Still Needs to Work

Search deserves its own test because of the Default-zone requirement discussed earlier.

If the existing Default zone continues using Windows authentication and users access SharePoint through an OIDC-enabled extension, verify that the Search Content Access Account can still crawl the Default-zone URL successfully. For example, users may access:

https://portal.contoso.com

while Search crawls:

http://portal.contoso.local

Both URLs ultimately represent the same SharePoint web application, but they provide different authentication paths.

After introducing OIDC, perform a full or incremental crawl and check the Search crawl logs rather than assuming Search remains unaffected.

Sign-Out Behavior

Sign-in usually receives most of the attention during an OIDC implementation, but sign-out should be tested as well. There can be multiple sessions involved. SharePoint has its session, while the identity provider may maintain its own authenticated session. Depending on the provider and trust configuration, the trusted identity token issuer can include the provider’s sign-out URL:

-SignOutUrl $signOutUrl

Test what actually happens when a user signs out. Sign into SharePoint, sign out, and then browse back to the SharePoint site. Determine whether the user is prompted to authenticate again or immediately signed back in because an active session still exists at the identity provider.

Neither behavior is automatically wrong. What matters is understanding the experience and making sure it matches what the organization expects.

Certificates and Signing Keys Have a Lifecycle

OIDC relies heavily on cryptographic validation, which means certificate and key lifecycle management needs to be part of the operational design. The identity provider signs tokens. SharePoint needs the corresponding public signing information so it can verify that the token genuinely came from the provider and has not been modified. Those signing keys can change.

If the trust uses manually imported certificates or RSA public keys, someone needs to own the process of monitoring and updating them when the identity provider rotates its signing keys.

Metadata-based configuration can reduce that operational burden where it is supported. On current SharePoint Server Subscription Edition builds, the metadata refresh functionality can keep the trusted provider information synchronized with the metadata feed.

The nonce certificate also has a lifecycle. It has an expiration date and needs to be monitored like the other certificates used by the farm. A simple way to review SharePoint-managed certificates is:

Get-SPCertificate |
    Sort-Object NotAfter |
    Select-Object `
        FriendlyName,
        Subject,
        NotBefore,
        NotAfter

Certificates used for authentication should not be something you discover has expired because users suddenly cannot sign in.

Troubleshooting OIDC

OIDC troubleshooting becomes much easier when you stop treating the authentication process as one big operation. Work through it in layers:

If the browser never reaches the identity provider, there is little value in troubleshooting the claims inside the returned ID token.

If the identity provider rejects the authentication request, start with the client identifier, application configuration, redirect URI, and authorization endpoint.

If authentication succeeds at the provider but SharePoint rejects the response, look at the issuer, audience, signing information, nonce configuration, and trusted identity token issuer.

If authentication succeeds but the user receives Access Denied, look at the resulting Claims identity and SharePoint permissions rather than immediately changing the OIDC endpoints.

Separating the authentication flow this way removes a lot of guesswork.

Useful PowerShell for Troubleshooting

Start with the trusted identity token issuer:

Get-SPTrustedIdentityTokenIssuer |
    Format-List *

Or inspect the specific provider:

Get-SPTrustedIdentityTokenIssuer `
    -Identity $providerName |
    Format-List *

Check the web applications:

Get-SPWebApplication |
    Select-Object DisplayName, Url

Review Alternate Access Mappings:

Get-SPAlternateURL |
    Sort-Object Zone |
    Format-Table `
        IncomingUrl,
        PublicUrl,
        Zone

Review the SharePoint-managed certificates:

Get-SPCertificate |
    Format-Table `
        FriendlyName,
        Subject,
        NotAfter

I would eventually turn these commands into a reusable OIDC validation script that outputs the provider, claims, web application configuration, zones, URLs, and certificate status in one place. That makes comparing a working farm against a problem environment considerably easier.

Before You Move to Production

Working authentication isn’t the finish line. Test the complete authentication and authorization path before treating the implementation as finished.

At a minimum:

• Test a normal user, an elevated-permissions user, a user who should be denied, and users receiving different claims from the provider.
• Verify role or group claims independently rather than assuming they work because individual users can sign in.
• Confirm Search continues crawling successfully.
• Confirm People Picker resolves identities in a usable way.
• Understand and test sign-out behavior.
• Check integrations, custom solutions, workflows, Office clients, and APIs that may have assumptions about how users authenticate.

Treat this as an authentication architecture change, not simply the creation of another SPTrustedIdentityTokenIssuer.

Pre-Production Checklist

Before moving users onto the OIDC-enabled URL, I would verify the following:

• The OIDC URL uses HTTPS with a valid certificate.
• DNS resolves correctly from every required network.
• The identity provider’s client or application configuration is correct.
• Every redirect URI exactly matches the SharePoint URL.
• The issuer and client identifier match what SharePoint expects.
• Signing certificates or RSA public keys are trusted correctly.
• The nonce certificate is configured and its expiration is monitored.
• The identifier claim is unique, stable, and consistently returned.
• Additional claims required for authorization are present and mapped.
• People Picker behavior has been tested.
• Search continues crawling through a Windows-authenticated Default zone.
• Sign-in and sign-out behavior has been validated.
• SharePoint permissions have been tested using the resulting OIDC Claims identities.
• Certificate and signing-key rotation procedures have been documented.

Most of the difficult OIDC problems I run into aren’t really caused by OIDC itself. They come from one of the surrounding components not matching what the other side expects.

Where OIDC Fits in a Modern SharePoint Architecture

NTLM and Kerberos remain useful for Windows authentication inside the traditional Active Directory trust boundary. SAML remains a valid federation option and still runs perfectly well in plenty of SharePoint environments. OAuth continues to matter for authorization scenarios where applications need controlled access to resources. OIDC adds a modern federation option focused on establishing user identity. These aren’t five different ways of doing the same thing.

A single SharePoint farm can reasonably use several of them at the same time. Search might authenticate against the Default zone using Windows authentication, users might authenticate through OIDC in another zone, and an integration might separately use OAuth for API authorization. That’s a perfectly normal architecture.

If I were designing new federated authentication for SharePoint Server Subscription Edition today, OIDC would be high on the list. That isn’t simply because it is newer than SAML. Newer does not automatically mean better.

The value is that OIDC aligns with the identity protocols and application patterns already being used across modern platforms. It uses OAuth 2.0 underneath, typically uses JWTs for ID tokens, supports metadata-based discovery, and fits naturally with modern identity providers.

If Microsoft Entra ID already governs authentication policy for your cloud applications, using it as the OIDC provider for an on-premises SharePoint environment can provide a more consistent authentication experience while SharePoint itself remains exactly where it is.

Entra ID Is an Example, Not a Requirement

Microsoft Entra ID is likely to be the obvious identity provider for many organizations, but it is important not to confuse the example with the requirement. SharePoint Server Subscription Edition supports OIDC. Entra ID is one identity provider capable of participating in that authentication flow. Microsoft also documents AD FS as an OIDC identity provider for SharePoint Server. Other OIDC providers may also be possible where they can provide the issuer, endpoints, signing information, claims, and protocol behavior SharePoint requires.

That is why understanding the trust itself is more valuable than memorizing a particular Entra walkthrough.

Once you understand what New-SPTrustedIdentityTokenIssuer is actually defining, it becomes much easier to evaluate another identity provider. You need to know who issues the token, what audience SharePoint should expect, how SharePoint validates the signature, which claim identifies the user, and where the authentication endpoints are.

The administrative interface used to configure those values at the identity provider can change. The SharePoint requirements underneath them do not.

Authentication Isn’t Authorization

One distinction is worth repeating because it is easy to lose track of during an OIDC project:

OIDC modernizes authentication. It does not redesign SharePoint authorization.

After authentication completes, SharePoint still decides what the resulting Claims identity is allowed to do. Site collection administrators, SharePoint groups, permission levels, unique permissions, and securable objects continue controlling access.

A user who successfully authenticates through Entra ID but has not been granted access to a SharePoint site still doesn’t get access. OIDC doesn’t change that. Likewise, if a role or group claim needs to participate in authorization, it needs to be deliberately returned, mapped, and used appropriately. Simply existing within the identity directory is not enough. That separation is a strength rather than a limitation. The identity provider handles identity. SharePoint keeps handling access.

Final Thoughts

OIDC is one of the more important authentication improvements in SharePoint Server Subscription Edition because it gives on-premises SharePoint a modern, standards-based way to federate with an external identity provider without moving SharePoint into the cloud and without replacing the Claims architecture underneath it.

There are several moving parts, but once you understand what each one does, the architecture becomes much easier to follow.

• New-SPClaimTypeMapping defines how incoming identity information is understood.
• New-SPTrustedIdentityTokenIssuer establishes the trust with the OIDC provider.
• New-SPAuthenticationProvider makes that trust available as an authentication option for a SharePoint web application.

The web application and zone configuration determine where users can actually use that authentication provider.

The identity provider authenticates the user and issues the ID token. SharePoint validates the issuer, audience, signature, nonce, and claims before turning that trusted identity into a SharePoint Claims identity. Once that happens, the normal SharePoint authorization model takes over.

For an existing environment with stable SAML or Windows authentication, there is no reason to change simply for the sake of using a newer protocol. Authentication changes have consequences, particularly where existing Claims identities already have permissions throughout the farm.

For a new federated authentication design, or an organization looking to align SharePoint Server with a broader modern identity strategy, OIDC is absolutely worth considering. It provides a modern authentication boundary while allowing the SharePoint platform behind it to continue operating in the way we already understand.

There are still SharePoint-specific details that need planning. HTTPS is required. Search still needs Windows authentication available through the Default zone. People Picker and Claims resolution need to be considered. Signing keys and certificates have lifecycles. The identifier claim needs to be selected carefully because it becomes part of how SharePoint understands the user. None of those are reasons to avoid OIDC. They are reasons to design it properly.

The simplest way I have found to think about the whole thing is this: SharePoint no longer needs to own the entire authentication experience. It needs to know **which identity provider it trusts, how to validate what the provider sends back, and how to turn that trusted identity into a SharePoint Claims identity**.

OIDC changes how the user proves who they are. SharePoint still decides what that identity is allowed to do.

That distinction is really the foundation of the entire implementation. Once it clicks, the PowerShell stops looking like a collection of obscure parameters and starts looking like a logical sequence of trust decisions.

For SharePoint Server administrators who have spent years working with NTLM, Kerberos, Claims, and SAML, OIDC is not a completely different security model that requires throwing away everything we already know. It is another authentication option built into the SharePoint Claims architecture, but one that fits much better with the way modern identity platforms work today. That is why it matters in SharePoint Server Subscription Edition.