A field report on serving Google's Gemma 4 E2B on AWS EC2 **G5g* — a Graviton2 (aarch64)
host with an NVIDIA T4G (Turing, SM 7.5) GPU. Three obstacles: an arch list nobody
publishes for this combination, a version floor that only the newest vLLM clears, and
64 KiB of shared memory that stops the model dead. Plus the seven things I documented
wrong before I had a box.*

G5g is the only instance AWS has ever shipped that puts an NVIDIA GPU behind a Graviton
host. It launched in 2020, it never got a successor, and Graviton is now on its fifth
generation without one.

That matters more than it sounds. The Arm-plus-CUDA world moved on to NVIDIA's own Arm CPU
— Grace, paired with SM 9.0 and 10.0 parts. Turing stayed well supported, on x86. G5g is
the only hardware that is aarch64 and compute capability 7.5, and almost nobody publishes
a build for that combination.

I put a rig on one anyway. The packaging problem was the quick part. Everything after it
— a compiler that was not there, a version floor I did not expect, and 32 KiB of shared
memory — took far longer, because none of it fails where you are looking.

No published build covers aarch64 and SM 7.5 together

Start with the obvious candidate. vllm/vllm-openai:v0.27.1 publishes both platforms under
one tag, and you can read the arch lists straight out of the image config without pulling a
layer:

docker buildx imagetools inspect vllm/vllm-openai:v0.27.1 --format '{{json .Image}}'

linux/amd64   7.5 8.0 8.6 8.9 9.0 10.0 12.0
linux/arm64       8.0 8.7 8.9 9.0 10.0 11.0 12.0

The one architecture this hardware needs is the only entry the two images disagree on. The
arm64 list is Ampere and up, because that is what ships as an Arm-plus-NVIDIA system: A100,
Jetson Orin, GH200, Blackwell. Turing is not on that list and never will be.

Normally a missing target degrades to JIT from embedded PTX. Not here. The Dockerfile says
so, with a comment:

# Do not add +PTX here: vLLM filters torch's top-level PTX flag when it
# converts global gencode flags into per-kernel arch lists.

So it does not run slowly. It fails outright, with no kernel image is available for
execution on the device.

The rest of the ecosystem splits the same way. Check before you plan anything:

AWS ships the one PyTorch that still has Turing

This is the finding that saves the whole exercise, and I nearly wrote it off. I had assumed
PyTorch's aarch64 CUDA wheels lacked sm_75 and that a from-source PyTorch build was
coming. That is true of the PyPI wheels. It is not true of AWS.

Read on two different DLAMIs, on the box:

torch 2.7.0+cu128    ['sm_75', 'sm_90', 'sm_100', 'sm_120']
torch 2.12.0+cu132   ['sm_75', 'sm_80', 'sm_90', 'sm_100', 'sm_110', 'sm_120']

AWS sells G5g, so AWS keeps Turing in the build — right through PyTorch 2.12 on CUDA 13.2,
an image cut three months ago. PyTorch never needs building. Only vLLM's own kernels do,
and CMake takes the arch list without argument:

-- CUDA target architectures: 7.5
CMake Warning: Pytorch version 2.11.0 expected for CUDA build, saw 2.12.0 instead.

That warning is worth reading twice, and I come back to it below.

The PyTorch DLAMI has no compiler

Two things the DLAMI does not give you, neither of them documented anywhere I could find.

There is no nvcc. The image ships the driver and a torch built against CUDA, not the
toolkit. You need the keyring and cuda-toolkit-13-2 from NVIDIA's sbsa repo — not the
x86 one, which is an easy reflex to get wrong on an Arm box.

And vLLM now wants Rust. Its vllm-rs frontend needs setuptools_rust plus a toolchain,
and the failure is a bare ModuleNotFoundError: No module named 'setuptools_rust' thrown
from metadata generation, several minutes in.

The newest vLLM was the only one that worked

No vLLM tag pins torch 2.12. They go 2.11, then jump to 2.13. I reasoned that building older
code against a newer runtime was the safer direction, took v0.26.0, and spent an hour being
wrong about it.

It builds fine. It then dies on model load:

transformers.integrations.heterogeneity.configuration_utils.AmbiguousGlobalPerLayerAttributeError:
'head_dim' is a per-layer attribute and may vary across layers.

Gemma 4's head_dim is not one number, and current transformers refuses to hand out a
global value for it. vLLM's config converter was still doing a flat
getattr(config, "head_dim", 0). The per_layer_config handling that copes with it landed
in v0.27.2rc0 — not v0.27.1, which I also checked. The newest tag was the only one that
worked.

If you take one process lesson from this: reach for the latest release first, and make the
constraint say out loud what stopped you when you fall back.

Gemma 4's attention heads are not one size

With the build working the server still would not start, and this failure has nothing to do
with Arm or packaging. It is this model against this chip.

Gemma4 model has heterogeneous head dimensions
{'sliding_attention': 256, 'full_attention': 512}.
FA4 not available, forcing TRITON_ATTN backend.

Read that as a chain, because every link is load-bearing:

1. Gemma 4's sliding layers are 256 wide. Its global layers are 512.
2. Only FA4 or Triton support heterogeneous head dims at all.
3. FA4 is not available, so vLLM forces TRITON_ATTN.
4. That choice is not yours to make. VLLM_ATTENTION_BACKEND is not a recognised variable in v0.27 — it logs Unknown vLLM environment variable detected and carries on. I set it twice before I read the warning.
5. Triton's unified attention kernel at head_size=512 wants about 96 KiB of shared memory per block.

64 KiB is the whole problem

Turing's shared memory is two numbers, and both are real. The default static limit per block
is 48 KiB — that is what torch.cuda.get_device_properties().shared_memory_per_block reports,
49,152 bytes. A kernel that needs more has to opt in through the dynamic shared-memory
attribute, and even then it tops out at 64 KiB. Ampere and later have 164 KiB and up.

Triton opts in, so it is measuring against the 64 KiB ceiling. It still does not fit:

triton.runtime.errors.OutOfResources: out of resource: shared memory,
Required: 98304, Hardware limit: 65536

Refused outright. Not slow, not degraded — the kernel will not launch, and it takes the
engine down during CUDA graph capture, which is late enough that you have already watched
the weights load and the KV cache get sized.

The fix is small. Shrink the KV tile until the query block and the K/V tiles fit inside the
budget, and drop the software pipeline to one stage. Gate it on pre-Ampere so it is a no-op
on every other card:

if current_platform.get_device_capability()[0] < 8:
    _smem_budget = 60000
    _esz = q.element_size()
    def _fits(t): return (BLOCK_M + 2 * t) * head_size * _esz <= _smem_budget
    while TILE_SIZE_PREFILL > 16 and not _fits(TILE_SIZE_PREFILL): TILE_SIZE_PREFILL //= 2
    while TILE_SIZE_DECODE  > 16 and not _fits(TILE_SIZE_DECODE):  TILE_SIZE_DECODE  //= 2
    launch_num_stages = 1

With that in vllm/v1/attention/ops/triton_unified_attention.py, graphs capture, the engine
comes up in 76 seconds, and the model serves. This is not upstream. It lives on my
instance and has to be reapplied on any vLLM upgrade, which makes it the obvious thing to
send back.

Most of the build is kernels that can never load

67 minutes on a g5g.4xlarge at MAX_JOBS=12, and the majority of it is FlashAttention.
vLLM compiles FA2 and FA3 regardless of TORCH_CUDA_ARCH_LIST — I watched it grind
through hundreds of sm90 Hopper instantiations on a build targeting 7.5 only. FA2 needs
sm80, FA3 needs sm90. Neither can ever load on this card.

Constraining VLLM_FA_CMAKE_GPU_ARCHES should cut that dramatically. I did not try it,
because by the time I understood what I was looking at the build was 45 minutes in and
interrupting it would have cost more than finishing.

What I got wrong before I had hardware

I wrote the rig's documentation before provisioning anything. Seven claims in it were wrong,
and every correction came off the machine rather than out of an argument. This is the part I
would keep if I kept nothing else.

That last one has teeth. If you health-check by testing for an empty response, this endpoint
passes while producing nonsense. Use /v1/chat/completions and read the text.

One claim is still standing only because I never tested it: whether g5g.xlarge's 8 GiB of
host RAM can stage 9.5 GiB of weights. Safetensors loading is mmap-backed, so I suspect it
can. It is labelled untested rather than stated as fact, which is where it should have been
all along.

What it does once it runs

content: 'Site Reliability Engineering (SRE) is a discipline that applies
          software engineering principles to infrastructure and operations
          problems to create highly reliable, scalable, and efficient systems.'
finish_reason: stop      usage: 19 prompt / 32 completion / 51 total

Before reading too much into 43 tok/s, note what the memory does. The T4G has GDDR6, not
HBM — 256-bit bus at 5,001 MHz, so 320 GB/s theoretical. I measured 277 GB/s on a
streaming read (87% of peak) and 234 GB/s on a read-modify-write. Decode is bandwidth-bound,
so 277 is the real ceiling. For scale, a TPU v5e is about 859 GB/s normalized and a v6e about
1,638 — this part has roughly a third of one and a sixth of the other. It is a bandwidth-limited
card behaving like a bandwidth-limited card.

Single run, single stream, no repeats and no variance figure. One sample per cell, and taken
with the clamped tiles, so it is a floor rather than a characterisation. My Inferentia port
measured about 44 tok/s for E2B on one core, which is the same neighbourhood — but that is a
different harness on different silicon and I would not put the two in one table.

Troubleshooting quick reference

The short version

Take the AWS ARM64 GPU PyTorch DLAMI — it is the only maintained aarch64 stack that still
carries sm_75. Add cuda-toolkit-13-2 from the sbsa repo and a Rust toolchain, because the
image ships neither. Build vLLM v0.27.2rc0 or newer from source with
TORCH_CUDA_ARCH_LIST=7.5 and use_existing_torch.py, and patch the Triton attention kernel
to fit Turing's shared memory before you try to start it. Serve with --dtype float16 and
--kv-cache-dtype auto.

Nothing here failed loudly, and nothing failed where I was looking. The packaging gap I built
the rig around was already solved by AWS; the thing that actually stopped me was 32 KiB of
shared memory and a model whose global attention heads are twice as wide as its sliding ones.
Hardware this far off the mainstream will keep producing that shape of surprise — the fix is
not to reason harder about it, but to get to a box sooner and let it tell you.

Measured on EC2 g5g.4xlarge spot, us-east-1a. NVIDIA T4G, compute capability 7.5,
15,360 MiB, driver 595.71.05. Deep Learning ARM64 AMI OSS Nvidia Driver GPU PyTorch 2.12
(Ubuntu 24.04). torch 2.12.0+cu132, CUDA 13.2. vLLM 0.27.2rc1.dev0+g7f7a32cfe built from
v0.27.2rc0.

The GitHub Universe 2026 schedule just dropped, and it’s full of exciting sessions, demos, and panels covering the potential of AI-powered development.

If you haven’t registered yet, here’s what you need to know. This two-day event brings together some of the greatest minds in tech, with experts from companies like AMD, Figma, NVIDIA, Coinbase, Anthropic, and OpenAI leading our sessions. They’re covering everything from delegating real work to Copilot and measuring AI at enterprise scale to fine-grained security for MCP servers. You’ll also have the chance to chat with the GitHub team one-on-one, get your questions answered, and even pick up some career advice.

Did we mention the Ship & Tell sessions where teams show what they’ve built, and partner booths where you can demo the latest tech?

• When: October 28-29
• Where: Fort Mason Center, San Francisco, CA

One thing first: register before August 19 and save $300 with Early Bird passes. Prices go up after that, so if Universe is already on your list, now’s the moment. The best part? You can stack savings with our group discounts.

Here’s a sneak peek of some of the sessions we have planned. You can jump to the full agenda right here. Be sure to mark your favorites to build your own personal calendar.

Find your flow

Some of the best moments at Universe happen heads-down: working through a real problem, configuring something on your own machine, and walking out with a project you can actually use. This year’s catalog leans into that with learnings you can take straight back to your repositories.

A few sessions to start with:

Stop prompting, start delegating: Configure Copilot to own the work
Ken Muse, GitHub; Mickey Gousset, GitHub
Learn how the right Copilot configuration turns AI into something you can trust with complex tasks. Layer Copilot’s full stack onto a TypeScript app, and you’ll leave with a working project and a clear sense of which capability fits which task, so you can delegate more and prompt less.

Inside GitHub Copilot’s coding harness: Optimizing across every model
Julia Kasper, Microsoft
Shipping a coding agent that works across OpenAI, Claude, Gemini, and whatever drops next week takes a harness. See the evaluation framework the GitHub Copilot team uses to test and optimize its agent across every model: reproducible benchmarks, thousands of autonomous coding tasks, and LLM-graded assertions that catch regressions before users do.

Stop waiting on your own pull requests: GitHub stacked pull requests in practice
Sameen Karim, GitHub
Stacked pull requests let you split changes into smaller, dependent pull requests that move through review efficiently while preserving the full picture. This demo builds a stack with the GitHub CLI, reviews it on github.com, and merges each pull request as it’s ready—so you leave with a workflow you can use tomorrow.

Find your people

Hallway conversations, a question that reframes your whole approach, the engineer who already solved the thing you’re stuck on. This year’s agenda is filled with sessions for exactly that. Plus, hallway tracks, partner booths, and Ship & Tell sessions where teams show what they’ve actually built.

A few sessions worth your time:

Building AI fluency at UPS
Jared Hatfield, UPS
Getting developers to try GitHub Copilot is simple; getting them fluent with it—using agents to plan, write, and ship real work—is the harder challenge. See how UPS moves developers from awareness to fluency, why motivation and measurement matter as much as the tooling, and where to focus first at enterprise scale.

Code is the easy part: Building Home Assistant in the open
Franck Nijhof, Open Home Foundation
“Building in the open” usually means one thing: code on GitHub. But the hard work starts long before code—ideas, UX, design, architecture, the roadmap itself. At Home Assistant, every step happens in the open across 20,000 contributors and a dozen GitHub organizations. See how the Open Home Foundation runs its whole roadmap with issues, projects, and discussions, including the harder parts, like being wrong in public, fixing it in public, and proving you don’t have to be technical to contribute.

I made my Octolamp think with GitHub Copilot CLI hooks
Beatris Mendez Gandica, Nuevo Foundation
What if your desk lamp could show when GitHub Copilot CLI is thinking? Using the native hooks system, Beatris Mendez Gandica made hers breathe green when the agent works, go white when idle, and blink red on errors. No prompting tricks, just system-level lifecycle events driving a physical light via the WLED API. In this session, you’ll see how Copilot CLI hooks work under the hood, and leave knowing how to write your own for any use case.

Build what’s next

Want to know what’s on the horizon? These are the talks that pull back the curtain on where AI-assisted development is heading.

The view from the labs: What’s next for AI-assisted development
Cara Phillips, Anthropic; Rohan Varma, OpenAI; Kate Catlin, GitHub
The people building frontier AI models see where capabilities are heading before anyone else. This interactive panel brings leaders from Anthropic, OpenAI, and other labs that power GitHub Copilot together for a candid look at the next two years of AI-assisted development, and what it means for you.

Open pull requests, don’t merge them: Fine-grained authorization for hosted MCP servers
Nick Taylor, Pomerium
Hosted MCP servers hand every agent everything its human can do: OAuth in, broad scope out, one global toggle. But what if an agent should open a pull request and leave the merge to a reviewer? See a pattern that works today: an identity-aware proxy that adds per-identity authorization in front of any hosted MCP server with no changes upstream, demonstrated live with Copilot doing exactly that.

From writing code to managing agents: Scaling 50+ services at GitHub
Anjuan Simmons, GitHub
GitHub’s Lifecycle team traded hand-coding fixes across 50+ services for an agentic pipeline where AI agents classify issues, research codebases, write implementation plans, and open draft pull requests automatically. Get the real lessons and numbers from running it at GitHub’s own scale: how it was built with GitHub Actions and Copilot, where automation pays off most, and why engineers still deliberately write some code by hand.

Cast your vote!

Three breakout sessions are heading to Universe this year, but we need your help deciding which one makes it to the main stage. Read through the descriptions, then cast your vote before August 21. Whichever session wins will also be available on demand, so even if you can’t join us in person, your vote shapes what you’ll get to watch later.

Session 1: Why sketching in code matters more in the age of AI
Qianqian Ye, Processing Foundation / University of Southern California; John Maeda, GitHub
AI can generate clean, working code from a short prompt, so the real question now is how to understand what’s been made. Qianqian Ye draws on teaching creative coding at USC and leading p5.js to show why sketching and thinking in code builds the intuition to shape systems, not just prompt them.

Session 2: Still open: How AI reshaped open source
Angie Jones, Agentic AI Foundation; David A. Wheeler, The Linux Foundation; Priya Pahwa, Django Software Foundation
Open source is being stress tested. While AI has accelerated contributions, it’s also raised hard questions about quality, governance, and the power of community when bots can contribute at machine scale. In this session, you’ll learn why AI makes open source more essential than ever.

Session 3: The human side of AI: How building community drove 94% Copilot adoption
Brittany Istenes, Independent
What if scaling AI isn’t about better models, but better human connection? A large U.S.-based financial services firm hit 94% Copilot adoption and 78% agent-written code, and the driving force was community, not tooling. In this session, you’ll discover how grassroots engagement, storytelling, and innersource made AI something developers actually wanted to use and build together.

Learn more

Want to get even more out of your GitHub Universe experience?

When you register, you can add a Day of Learning pass for $50, which includes access to a full day of learning at GitHub HQ plus one GitHub Certification exam voucher.

Already have your agenda planned? You can also purchase a GitHub Certification exam voucher as a standalone add-on for $30 and validate your skills after the event.

See you in SF!

The post Your guide to GitHub Universe 2026 is here: The schedule just launched! appeared first on The GitHub Blog.

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.

Immigrant founders have built some of the world’s most valuable companies, but many still face barriers that make it harder to get a startup off the ground. Visa restrictions, limited access to friends-and-family capital, shallow networks, and a venture industry built around pattern matching can keep promising founders from getting funded before they have a chance to prove themselves.

In this episode of Build Mode, host Isabelle Johannesen sits down with Manan Mehta, co-founder and managing partner of Unshackled Ventures, to talk about why he believes immigrant founders represent one of venture capital’s biggest overlooked opportunities. Manan breaks down how Unshackled built an investment model designed to help founders navigate immigration barriers, why traditional VC pattern matching causes investors to miss potential outliers, and how his team evaluates founders at day zero—often before they have a product, customers, or traction. He also explains why the structural gaps that make some founders harder to fund may be exactly where investors should be looking for outsized returns.

They get into:

• The four structural barriers immigrant founders face when starting companies in the U.S.

• How Unshackled Ventures helps founders navigate visas while building their startups

• Why VC’s reliance on pattern matching can cause investors to miss outlier founders

• How Manan evaluates founders before they have a product, customers, or traction

• The IQ, AQ, EQ, and SQ framework Unshackled uses to evaluate founder potential

• Why resilience, lived experience, and a founder’s relationship to the problem can matter more than a polished pitch

• Why structural gaps can create some of the biggest opportunities for investors

• How founders without traditional networks can find alternative paths to early capital

• Why founders should understand their personal “why” instead of trying to fit the traditional VC mold

Subscribe to Build Mode on Apple Podcasts, Spotify, or wherever you like to listen. And watch the full videos on YouTube. New episodes of Build Mode drop every Thursday.

Chapters:

00:00 – Why VCs Miss Outlier Founders

01:45 – Why Manan Mehta Founded Unshackled Ventures

04:15 – The Problem With VC Pattern Matching

06:15 – The Friends-and-Family Gap for Immigrant Founders

08:18 – How Unshackled Helps Founders Navigate Visas

10:40 – Building a Startup in Today’s Immigration Environment

12:19 – Solving One of Unshackled’s Hardest Immigration Cases

14:39 – What the U.S. Stands to Lose16:59 – Raising Unshackled’s First Venture Funds

19:40 – Can You Start a Company on an H-1B Visa?

22:13 – How to Evaluate a Founder at Day Zero

28:30 – Measuring IQ, AQ, EQ, and SQ

30:26 – How Fear Drives VC Pattern Matching

33:01 – Why Structural Gaps Create Outlier Opportunities

35:14 – Finding Startup Capital Outside Traditional VC

38:09 – Why Founders Need to Understand Their “Why”

Hosted by Isabelle Johannesen. Produced and edited by Maggie Nye. Audience development led by Morgan Little. Special thanks to the Foundry and Cheddar video teams.

Added

• Add --enable-mcp-server to re-enable MCP servers disabled in settings for the current run
• A session shared with another CLI now says so: in --ahp mode a row for a session you have joined leads with 2 clients (or more) when somebody else is attached to it, in both the Sessions tab and the sidebar, and /ahp status reports the same number. Presence is announced on attach and refreshed on a heartbeat, so a client that joins shows up at once and one that goes away stops being counted
• /ahp cloud <environment-id> puts a Mission Control environment in the Sessions tab's source picker alongside your local daemons, so the compute --cloud runs on is somewhere you can switch to with h and create sessions on — marked CLOUD, because Mission Control wakes it on connect and this CLI cannot start or stop it
• /ahp codespace <name> forwards a Codespace's copilotd port to your machine with gh and puts it in the Sessions tab's source picker, so a session running in a Codespace is one h away. It is named after the Codespace and marked CS, the tunnel closes when you exit or with /ahp stop <name>, and a missing codespace scope tells you the gh auth refresh line to run
• --ahp now finds the AHP daemons already running on your machine and puts them in the Sessions tab's source picker, so a host you started in another terminal is there without being named again -- including one you start while the CLI is open. Turn it off with COPILOT_AHP_DISCOVER=0
• In --ahp mode the Sessions tab and the sidebar now list the host's sessions — including ones started by another CLI — so enter joins a session running elsewhere, n creates the new session on the host, and closing a row disposes it there for every attached CLI; each host row shows whether that session is running, waiting on input, or idle right now, and the busy ones sort to the top of the host's list; every row that lives on the host is marked with it, including the sessions you have already joined, so a shared session no longer reads like a private local one, and a host session is listed once instead of reappearing lower down as a stale local copy of itself
• In --ahp mode the Sessions tab and the sidebar now show the host itself above the list — which daemon these sessions come from, what it is running (copilotd 0.6.5), and whether it is still answering — so a host that stops responding is visible instead of leaving every host row on screen as a photograph; losing the host is also announced once in the timeline, since that is rarely the screen you are looking at, and /ahp status now reports the same identity and health plus whether this CLI started the daemon or attached to one that was already running
• /ahp start [port], /ahp stop <host> and /ahp restart <host> manage the AHP daemons themselves from inside the CLI. start serves the current directory, so it is the fix for a healthy host refusing a new session with permission denied; stop only ever signals a process it can see is an AHP host on this machine, waits for the socket to close, and asks for --force before disconnecting the session you are in; restart relaunches on the workspace the daemon was already serving (staff-only for now: --ahp and /ahp are gated on the AHP_CLIENT feature flag)
• The Sessions tab now shows where its sessions come from -- this CLI process first, then every AHP daemon you named -- with each host's health beside it, and h switches between them. --ahp and COPILOT_AHP_URL take a comma-separated list of hosts, /ahp connect <url> adds one live, /ahp hosts lists them and /ahp use <host> switches from the timeline. The list shows only the selected source's sessions and n creates there, so attaching to a host is no longer a one-way door away from your local sessions
• copilot --ahp attaches the CLI to an Agent Host Protocol host, so sessions live on the host instead of in the CLI: several terminals can attach to the same session and watch its turns stream live, /ahp sessions|attach|new reaches the host's session list, and a bare --ahp starts a local host when none is running; typing while a turn is streaming — including a turn another terminal started — behaves as it does locally: enter steers the prompt into the running turn, ctrl+q queues it for the next one, ctrl+c takes it back, and every attached terminal sees it either way (staff-only for now: --ahp and /ahp are gated on the AHP_CLIENT feature flag)
• Add /plugin marketplace update [name] to refresh marketplace catalogs
• Add support for MAI Code 1.1 Flash
• Add --usage-output-file to write final usage metrics to a JSON file
• Set explicit objectives with /autopilot without experimental mode

Improved

• --cloud now puts the environment it provisions in the Sessions tab's source picker, so the compute your cloud session runs on is somewhere you can switch back to, create more sessions on, and inspect with /ahp
• /ahp codespace now accepts the display name you gave a Codespace, not just the auto-generated one gh prints — and when the name matches nothing it lists the Codespaces you do have, or says the account has none, instead of reporting a 404 URL
• The Sessions tab's source strip is now drawn as the same chip the filter: scope selector uses -- the source in force is a bold value on a filled badge, in the same fonts, foregrounds and backgrounds -- instead of a hand-rolled line of ASCII brackets and glyphs in a visual language of its own. It keeps its own line directly above filter: and still names every source -- each daemon marked AHP so it is clear the sessions are not this process's -- separated by the same · a session card uses, with h moving the highlight along it. Every entry reserves the badge's padding whether or not it is selected, so the line never re-flows as the highlight moves. Each host's health rides on the colour of its own entry, and where the line cannot hold every source -- the docked sidebar is around 42 columns -- it collapses to the source in force and counts what it could not draw, instead of silently truncating the selected host's address mid-number
• Show LSP progress percentages in all service states and clear them when progress ends
• Spec plugins that leave commands, agents, rules, hooks, LSP or MCP config at the plugin root now report the file and where to move it, instead of losing the component silently
• MCP server timeout settings now apply to tool discovery, with a 30-second default so slow servers can load their tools reliably.
• Improve CLI rendering performance for streaming assistant output
• Show per-file headers when viewing expanded multi-file apply_patch diffs
• Show /autopilot and /goal objective hints in slash-command autocomplete
• Show structured ask_user forms by default in interactive CLI sessions
• When an enterprise policy requires the sandbox, --no-sandbox now explains that it was ignored instead of silently having no effect.
• extraKnownMarketplaces "autoUpdate" is now honored from managed (MDM/server) settings too, not just user settings

Fixed

• copilot --ahp no longer fails with "no AHP host is listening" when daemons are running — it attaches to one already on this machine (preferring one whose workspace covers your directory) instead of insisting on the default address, and only reports a failure when there is genuinely nothing to attach to and none can be started
• /clear and /new are available again on a session that lives on an AHP host, and they now replace it on that host. Previously they were hidden because they built the replacement session locally: the timeline looked cleared, but every prompt after it ran in this process instead of on the host, and no other attached CLI could join it
• A --ahp host reached with a connection token (--ahp "wss://host:8765?tkn=…", how a Codespace or LAN host is protected) no longer prints that token back: /ahp status, the /ahp session lists, the connection errors and the host-status notices all redact the query string, so a transcript can be shared without leaking it. A host that refuses the upgrade with 401 now says the connection token is what it wants
• An --ahp session now runs in the directory you started the CLI from, when the host's workspace covers it, instead of always at the host's workspace root — so a daemon serving a parent directory no longer puts your agent in the wrong project
• Host skills no longer vanish from an --ahp session moments after it opens: a relay reconnect snapshot that omits customizations is no longer read as "the host has none"
• The status line no longer sits on Loading: … — still waiting on extensions for the whole life of a session that runs in another process — every --ahp session, and Mission Control remote sessions too. The CLI cannot load its extensions into a session it does not own, and now reports that instead of waiting forever
• copilot init no longer silently drops --sandbox / --no-sandbox. The flag now applies to the init session, subject to the same feature gating and enterprise sandbox floor as other entry points.
• Sandboxed MCP servers launched with npx or uvx now get a writable Copilot-owned package cache, plus the Windows toolchain and Playwright browser grants they were missing (needs dev-tool access)
• A sandbox readonlyPaths entry nested inside your working directory now blocks writes from the built-in file tools
• Turning off sandbox.allowDevToolAccess now also withholds the tool directories discovered on PATH and in toolchain environment variables, such as a relocated CARGO_HOME.
• Footer AI credit total updates as background subagents spend, instead of waiting for the next turn
• Moved unknown and ineffective settings into an actionable /settings Problems tab and cleaned up retired CLI-owned keys
• Pressing Enter now always acts on your message instead of sometimes leaving it in the queue
• Very large sessions no longer fail to load their history after a rewind or a compaction

Removed

• Breaking: Agent Plugins spec plugins now read commands/, agents/, rules/, hooks/hooks.json, lsp.json, and extensions/ only under com.github.copilot/ — no longer from the plugin root