Using the ADFS userinfo endpoint instead of allatclaims

This post shows how to keep the ADFS ID token small and fetch extra claims from the OpenID Connect userinfo endpoint instead of using allatclaims. It covers the urn:microsoft:userinfo claim rules and the ASP.NET Core OpenIdConnect setting that merges those claims. It also flags the audience error that appears when the wrong token is sent.

Key points

• The userinfo endpoint lives at https://<adfs-server>/adfs/userinfo and is listed in the discovery document.
• Without an explicit resource, ADFS issues tokens for urn:microsoft:userinfo, so allatclaims is not needed.
• The claims returned are controlled by issuance transform rules on the urn:microsoft:userinfo resource.
• In ASP.NET Core, set GetClaimsFromUserInfoEndpoint = true to merge userinfo claims into the principal.
• Custom claims need a mapping such as ClaimActions.MapJsonKey in addition to that setting.
• A token issued for your API fails with MSIS9921 on userinfo; request a separate token and do not forward the userinfo token.

The allatclaims scope puts every claim into the ID token, which works until group memberships pile up and the token grows with every request. The userinfo endpoint offers a lighter route: the ID token stays small, and the application fetches extra claims on demand by sending an access token as a bearer. In ADFS the endpoint is tied to the urn:microsoft:userinfo resource, and the claim rules defined on that resource decide what comes back.

In ASP.NET Core, enabling GetClaimsFromUserInfoEndpoint in the OpenID Connect handler does the request for you, and custom claims need an explicit mapping. The main pitfall is audience: userinfo only accepts tokens issued for its own resource, so a token requested for your Web API will be rejected with MSIS9921. Keep the userinfo token in the web app and request a separate token for API calls, never forwarding the userinfo token to the API.

Real-world use

• An enterprise ASP.NET Core web app with many AD group memberships that wants a smaller ID token.
• A portal that loads department or manager attributes only on pages that need them.
• A web front end calling a separate Web API, where each needs its own correctly scoped access token.

Why it matters

.NET teams on ADFS can shrink their ID tokens by moving extra claims to userinfo, but must keep the userinfo and API tokens separate to avoid audience errors.

Related stories

• Shrinking the ASP.NET Core auth cookie with ITicketStoreBWBart Wullems (The Art of Simplicity)Oct 21
• A secure enterprise chat with React, .NET 10 and Microsoft FoundryDVDEV Community: #dotnet1 d ago
• ASP.NET Core Authentication & Authorization Explained: What to Use, When, and How to Ship It SafelyDVDEV Community: #aspnetcore1 d ago