All the .http posts are here.

I have done a few samples that illustrate native auth in EEID, but I was asked if .http files can be used in a normal browser-based flow.

The problem is that there doesn't appear to be any way to get an .http file to “pop up” a browser-based login screen.

So you have to do this outside the .http file, e.g., by typing the request into the browser or using PowerShell.

Here is a vibe-coded PS snippet:

<#
.SYNOPSIS
 Signs in to Microsoft Entra External ID (CIAM) using the standard OIDC
 authorization code flow and prints the resulting access token so you can
 copy/paste it (e.g. into the @accessToken variable in EEIDLogin.http).

.DESCRIPTION
 This mirrors the normal "Authenticate" browser experience:
   1. Opens the default browser to the tenant's /authorize endpoint.
   2. You sign in with username + password (and MFA, if required) on the
   real Entra External ID hosted sign-in page.
   3. EEID redirects the browser to a local redirect URI
   (http://localhost:8400/callback) with an authorization "code".
   4. This script runs a small local HTTP listener to catch that redirect,
   then exchanges the code for an access token at the /token endpoint.
   5. Prints the access token (and refresh token, if issued) to the console
   and copies the access token to your clipboard.

.NOTES
 Update $tenantSubdomain, $tenantId, $clientId, and $clientSecret below for
 your own tenant/app registration. The app registration's redirect URI must
 include http://localhost:8400/callback (added as a "Web" or "Public client"
 redirect URI, matching how the app is configured).
#>

$tenantSubdomain = "eeid-domain"
$tenantId        = "eeid-domain.onmicrosoft.com"
$clientId        = "d6...90"
$clientSecret    = "95...WB"
$redirectUri     = "http://localhost:8400/callback"
$scope           = "openid profile offline_access User.Read"

$authorizeEndpoint = "https://$tenantSubdomain.ciamlogin.com/$tenantId/oauth2/
                      v2.0/authorize"
$tokenEndpoint     = "https://$tenantSubdomain.ciamlogin.com/$tenantId/oauth2/
                      v2.0/token"

# Step 1: Build the authorize URL and start a local listener for the redirect
$state = [guid]::NewGuid().ToString("N")

$authorizeUrl = "$authorizeEndpoint`?" + (
 @(
  "client_id=$clientId"
  "response_type=code"
  "redirect_uri=$([uri]::EscapeDataString($redirectUri))"
  "scope=$([uri]::EscapeDataString($scope))"
  "response_mode=query"
  "state=$state"
 ) -join "&"
)

$listener = New-Object System.Net.HttpListener
$listener.Prefixes.Add("$redirectUri/")
$listener.Start()

Write-Host ""
Write-Host "=== Opening browser to sign in ===" -ForegroundColor Cyan
Write-Host "If a browser window doesn't open automatically, copy this URL 
            into one:"
Write-Host $authorizeUrl
Write-Host ""

Start-Process $authorizeUrl

# Step 2: Wait for the redirect carrying the authorization code
$context  = $listener.GetContext()
$request  = $context.Request
$response = $context.Response

$queryParams = [System.Web.HttpUtility]::ParseQueryString($request.Url.Query)
$code        = $queryParams["code"]
$returnedState = $queryParams["state"]
$errorParam  = $queryParams["error"]

$responseHtml = if ($errorParam) {
 "<html><body><h2>Sign-in failed: $errorParam</h2><p>$($queryParams
  ['error_description'])</p><p>You can close this tab.</p></body></html>"
} else {
 "<html><body><h2>Sign-in complete.</h2><p>You can close this tab and return 
  to PowerShell.</p></body></html>"
}

$buffer = [System.Text.Encoding]::UTF8.GetBytes($responseHtml)
$response.ContentLength64 = $buffer.Length
$response.OutputStream.Write($buffer, 0, $buffer.Length)
$response.OutputStream.Close()
$listener.Stop()

if ($errorParam) {
 Write-Error "Sign-in failed: $errorParam - 
   $($queryParams['error_description'])"
 exit 1
}

if ($returnedState -ne $state) {
 Write-Error "State mismatch - possible CSRF, aborting."
 exit 1
}

if (-not $code) {
 Write-Error "No authorization code was returned."
 exit 1
}

# Step 3: Exchange the authorization code for an access token
$tokenBody = @{
 grant_type    = "authorization_code"
 client_id     = $clientId
 client_secret = $clientSecret
 code          = $code
 redirect_uri  = $redirectUri
 scope         = $scope
}

$tokenResponse = Invoke-RestMethod -Method Post -Uri $tokenEndpoint -Body 
$tokenBody -ContentType "application/x-www-form-urlencoded"

Write-Host ""
Write-Host "=== Access token (copy everything between the quotes) ===" 
  -ForegroundColor Green
Write-Host $tokenResponse.access_token
Write-Host ""

if ($tokenResponse.refresh_token) {
 Write-Host "=== Refresh token ===" -ForegroundColor Yellow
 Write-Host $tokenResponse.refresh_token
 Write-Host ""
}

# Also copy the access token to the clipboard for convenience, if available
try {
 $tokenResponse.access_token | Set-Clipboard
 Write-Host "(Access token has also been copied to your clipboard.)" 
   -ForegroundColor DarkGray
}
catch {
 # Set-Clipboard isn't available in all PowerShell hosts; ignore if it fails.
}

Running this PS script gives:

=== Opening browser to sign in ===
If a browser window doesn't open automatically, copy this URL into one:
https://eeid-domain.ciamlogin.com/eeid-domain.onmicrosoft.com/oauth2/v2.0
  /authorize?
client_id=d6...90
&response_type=code
&redirect_uri=http%3A%2F%2Flocalhost%3A8400%2Fcallback
&scope=openid%20profile%20offline_access%20User.Read
&response_mode=query
&state=64770a6dc8ff42d386232cf1053059b7

=== Access token (copy everything between the quotes) ===
ey...xw

=== Refresh token ===
1.A...vT0

(Access token has also been copied to your clipboard.)

The .http file then looks like:

### Paste the access token you got from Get-EntraToken.ps1
@accessToken = ey...xw

GET https://graph.microsoft.com/v1.0/me
Authorization: Bearer {{accessToken}}
Accept: application/json

This results in:

{
  "@odata.context": "https://graph.microsoft.com/v1.0/$metadata#users/$entity",
  "businessPhones": [],
  "displayName": "Test User",
  "givenName": null,
  "jobTitle": null,
  "mail": null,
  "mobilePhone": null,
  "officeLocation": null,
  "preferredLanguage": null,
  "surname": null,
  "userPrincipalName": "d5...58@eeid-domain.onmicrosoft.com",
  "id": "d5..58"
}

Basically, this just doesn’t seem worth it.

It would be easier to just add the /me call to the PS script!!! 😃

All good!

Using a .NET .http file to do an authentication code flow in Entra External ID (EEID) was originally published in The new control plane on Medium, where people are continuing the conversation by highlighting and responding to this story.

I did a comparison two years ago, but things have changed, so I updated it.

This comparison is complicated because EEID supports both B2B and B2C functionality.

The table concentrates more on B2C, allowing a more direct comparison with Azure AD B2C.

This Learn article comparing workforce and external tenants may also be of use.

Some features require a Microsoft Entra ID P1 or P2 subscription.

Please note any errors and omissions in the comments, and I will update the article.

Note A

Facebook, Google and Apple

Note 1

EEID only has SAML SP support. It cannot act as an inbound SAML IDP to issue SAML 2.0 assertions directly to your own line-of-business applications

Note 2

B2C API connectors can be invoked anywhere in the custom policy flow, and multiple times.

EEID extensions cover:

TokenIssuanceStart AttributeCollectionStart OnAttributeCollectionSubmit OnOtpSend

Each extension can only be invoked once

Note 3

Native passwordless phone number sign-in (where a user types in just their phone number instead of an email address or username) is a feature reserved for workforce Entra ID tenants

Note 4

SMS-based text message verification is supported as a second-factor MFA option

Note 5

Authenticator push is not supported as an MFA method

Note 6

EEID supports native passkey (FIDO2/WebAuthn) sign-in; B2C does not support FIDO2/WebAuthn.

Customers can use platform and browser-native passkeys such as Windows Hello, iCloud Keychain, Google Password Manager, or third-party managers like 1Password and Bitwarden

Note 7

Entra ID feature (authentication methods policy, e.g. TAP) usable for passwordless onboarding, including initial passkey registration, in EEID

Note 8

EEID inherits full Entra ID Conditional Access (device/location/risk/session controls); B2C has limited CA functionality

Note 9

Risk-based sign-in and user risk policies require Microsoft Entra ID Protection, which is a feature built for workforce tenants (standard Entra ID backed by Entra ID P2 licenses) to protect internal employees and B2B direct guest collaborations

Note 10

You can hyperlink your custom Terms of Use and Privacy Policy URLs directly within the sign-up page layout/company branding text in EEID

Note 11

Features like lifecycle workflows, entitlement management (access packages/approval workflows), privileged identity management (PIM), and automated access reviews are workforce capabilities and do not exist in dedicated external tenants

Note 12

Typically done via custom policy orchestration steps in B2C, not Graph API

Note 13

EEID company branding lacks full CSS/JavaScript support that B2C custom policies allow

Note 14

Refer this

Note 15

EEID tenants can mix B2B guests and external/consumer users in one directory

Note 16

Separate Azure AD B2C portal blade, unified Entra/EEID admin centre

Note 17

Microsoft has signalled Azure AD B2C is in maintenance mode, with no new features planned. Microsoft will pull the plug in 2030

Note 18

B2C relies on webview / browser based redirects for login, whereas native auth allows for support for inline mobile logins

Note 19

Limited external claim mapping. There is no way to map additional claims (outside of the standard set)

All good!

A comparison between Azure AD B2C and Entra External ID (EEID) was originally published in The new control plane on Medium, where people are continuing the conversation by highlighting and responding to this story.

All the .http posts are here.

An “.http” file is just a plain text file with the “.http” extension. It uses a simple syntax to define one or more HTTP requests that you can run directly from your editor.

Syntax

• Variables (optional, reusable values)

Define variables at the top of the file and reference them later with “{{name}}”:

@baseUrl = https://graph.microsoft.com/v1.0
@token = eyJ…

• A request block

A request starts with an HTTP method and URL, followed by optional headers, a blank line, and then an optional body:

GET {{baseUrl}}/me
Authorization: Bearer {{token}}
Accept: application/json

• Separating multiple requests

Use a line containing “###” to separate independent requests within the same file:

### Get my profile
GET {{baseUrl}}/me
Authorization: Bearer {{token}}
### Create something
POST {{baseUrl}}/me/sendMail
Authorization: Bearer {{token}}
Content-Type: application/json
{
 "message": {
 "subject": "Test",
 "body": { "contentType": "Text", "content": "Hello" },
 "toRecipients": [{ "emailAddress": { "address": "someone@example.com" } }]
 }
}

Key syntax rules

- “# comment” or “// comment” — comment lines
- “@name = value” — define a variable reference with “{{name}}”
- “###” on its own line — separates independent requests in the same file
- Method + URL on one line (“GET”, “POST”, “PUT”, “DELETE”, etc.)
- Headers go on the lines right after, one per line (“Header-Name: value”)
- A blank line separates headers from the request body (if any)

Running the file

• For VS Code, install the “REST Client” extension (humao.rest-client), then click the “Send Request” CodeLens link that appears above each request, or press “Ctrl+Alt+R” with the cursor inside a request block
• For Visual Studio 2026, “.http" files are supported natively via the built-in
  HTTP editor — just open the file and click the run/send icon next to each request.

No special tooling is required to create the file — only to execute the requests inside it.

How does this compile?

An “.http” file is not source code — it isn’t parsed into an assembly, isn’t type-checked, and has no build step. It’s a plain-text description of raw HTTP requests, so a compiler has nothing to produce.

• No syntax requires compilation — the “@variable”, “###”, method/URL, headers, and body are just text that the editor’s HTTP client (REST Client in VS Code, or the built-in HTTP editor in Visual Studio) reads and sends over the wire at the moment you click “Send Request”
• No project reference or assembly output — unlike “.cs”/”.vb” files, “.http” files aren’t included in a project’s build (“.csproj”) compilation pass, so adding, editing, or saving one never triggers (or breaks) a build
• Execution happens live— each time you click “Send Request”, the tool substitutes variables (“{{baseUrl}}”, “{{token}}”, etc.) and fires the literal HTTP request immediately. There’s no intermediate step that transforms the file into something else first
• Instant edit-and-retry loop — because nothing is compiled, you can change the URL, header, or body text and resend the request right away without waiting for a build or restarting any process

In short, “.http” files are interpreted on the spot by your editor’s HTTP client, the same way a “curl” command or Postman request is “run” rather than “built”

Here’s an example:

# How to get an access token from Microsoft Graph Explorer:
# 1. Go to https://developer.microsoft.com/graph/graph-explorer
# 2. Sign in (top-left "Sign in" button) with the account you want to call 
#    Graph as.
# 3. Consent to the permissions you need (e.g. User.Read) when prompted.
# 4. Run any query (e.g. GET /me) by clicking "Run query".
# 5. Copy the token: Check the response panel's "Access token" tab if your 
#    version of Graph Explorer shows one.
# 6. Paste the copied token below as the value of the "token" variable 
#    (replacing the old one).
# NOTE: Tokens expire after ~1 hour, so you'll need to repeat this when it 
#       expires.

# How to send this request from VS Code:
# 1. Install the "REST Client" extension (humao.rest-client) from the 
#    Extensions marketplace.
# 2. Open this .http file in VS Code.
# 3. Click the "Send Request" link that appears above the GET line (CodeLens),
#    or place your cursor in the request block and press Ctrl+Alt+R.
# 4. The response opens in a side pane in VS Code.
# 5. If you update the token or base URL variables, just re-click 
#    "Send Request" to pick up the change.

@baseUrl = https://graph.microsoft.com/v1.0
@token = ey...sA
### Get the signed-in user's profile
GET {{baseUrl}}/me
Authorization: Bearer {{token}}
Accept: application/json

### Get the signed-in user's direct reports
GET {{baseUrl}}/me/directReports
Authorization: Bearer {{token}}
Accept: application/json

### Get more details about the signed-in user (select additional properties)
GET {{baseUrl}}/me?$select=displayName,givenName,surname,mail,
    userPrincipalName,jobTitle,department,officeLocation,mobilePhone,
    businessPhones,preferredLanguage
Authorization: Bearer {{token}}
Accept: application/json

Sadly, there doesn't seem to be any syntax to automatically pop up a login screen 😢 to get the access token.

The easiest way to get an access token is to use Graph Explorer, log in with the user, run a request and then copy the access token into the “@token = ey…sA” line in the script above.

VS automatically adds the “Send request” commands. That’s why you don’t see them in the samples I’ve included.

Running, e.g. the first command shows:

A common pattern is to use some variable returned in the previous response in the next request.

As an example:

### Get more details about the signed-in user (select additional properties)
# @name meDetails
GET {{baseUrl}}/me?$select=displayName,givenName,surname,mail,
    userPrincipalName,jobTitle,department,officeLocation,mobilePhone,
    businessPhones,preferredLanguage
Authorization: Bearer {{token}}
Accept: application/json

### Look up the same user by userPrincipalName (uses the value from the 
    previous response)
# NOTE: Send the "meDetails" request above at least once before sending this 
#       one, so Visual Studio has a cached response to pull 
#       userPrincipalName from
GET {{baseUrl}}/users/{{meDetails.response.body.$.userPrincipalName}}
Authorization: Bearer {{token}}
Accept: application/json

The first request (which we reference as “@name meDetails”) returns userPrincipalName, which we use in the second request.

Note: I used AI to write the VS Code parts, as I don’t use VS Code very often.

All good!

How to create a .http file from scratch was originally published in The new control plane on Medium, where people are continuing the conversation by highlighting and responding to this story.

The docs are here. The repo is here.

In EEID, ensure FIDO2 is enabled in Authentication methods.

Click on “Passkey”:

Click on “Configure”:

I use 1Password, so I need “Synced” enabled.

There are two modes:

• “Passwordless sign-in. The user enters their email or username. If a passkey is available, they’re prompted to sign in with face, fingerprint, PIN, or a security key. The passkey completes first-factor authentication and also satisfies multifactor authentication (MFA) requirements.
• Passkey for MFA. The user signs in with their email or username and password. If a passkey is registered, they complete MFA with the passkey — a phishing-resistant alternative to traditional verification methods”.

I just used the former.

For the latter, you need to create a CA policy.

You also need:

• “An account with at least the “Authentication Policy Administrator” role to configure passkey policies.
• A custom URL domain configured for your tenant. Passkeys are registered against the custom URL as the relying party”.

Note: Only “email + password” and “username + password” local accounts can register a passkey.

Some points to note from the docs:

Is Microsoft Authenticator supported for passkeys?

No. The Microsoft Authenticator app doesn’t currently support registering passkeys.

Can customers use a passkey on a different device from where they registered it?

Yes — synced passkeys are automatically available on all linked devices.

Can I enforce passkeys using Conditional Access authentication strengths?

No. CA works in EEID, but EEID tenants don’t currently support Conditional Access authentication strengths.

Can I use passkeys with email one-time passcode or social IdP users?

Not yet. Only email + password local account users can use passkeys currently.

Is there a cost for passkey authentication?

No. Passkeys are included in all Microsoft Entra External ID pricing tiers at no additional cost, unlike SMS-based MFA, which requires a linked subscription.

Are passkeys supported in Azure AD B2C?

No. Passkeys for customer-facing apps are available only in Microsoft Entra External ID (external tenants). If you’re on B2C, consider planning your migration to External ID.

Are there low-privilege APIs for building a credential management experience?

No. Use the FIDO2 provisioning APIs to build your credential management experience.

Are passkeys supported in mobile native authentication flows?

No. Passkeys aren’t currently supported through native authentication APIs.

Is there an out-of-the-box passkey registration experience?

No. Microsoft doesn’t currently provide a built-in passkey registration experience for external tenants. Build a credential management experience in your application by using the FIDO2 provisioning APIs.

Which is a nice segue into the repo!

The repo shows the out-of-the-box experience. It’s just a sample application and should not be deployed to production.

Follow the steps for:

• Edit the hosts file
• Generate an SSL certificate for the proper domain
• Use a test tenant and single-tenant app registration
• Register your redirect URI in the EEID portal

Application Configuration

My authConfig.js looks like:

auth: {
    clientId: '95...53', // This is the ONLY mandatory field that you need to 
      // supply.
    authority: 'https://ciam-tenant.ciamlogin.com/', // Replace the 
      // placeholder with your tenant subdomain 
    redirectUri: '/',
    postLogoutRedirectUri: '/',
    navigateToLoginRequestUrl: false,
},

and my env file looks like:

# Local dev hostname — must match the auth.<ciam-tenant>.ciamlogin.com 
# subdomain you added to your hosts file
# Example: auth.ciam-tenant.ciamlogin.com
VITE_HOST=auth.ciam-tenant.ciamlogin.com
VITE_PORT=3000

# SSL certificate filenames (generated locally — see README "Generate SSL 
# Certificate")
VITE_SSL_CERT=auth-cert.pem
VITE_SSL_KEY=auth-key.pem

# Client secret from your Entra app registration (do NOT commit your 
# real .env)
VITE_APP_SECRET=qH...au

Note: You need a client secret from your app registration. This step is missing in the docs.

Note: The docs list “a custom URL domain configured for your tenant” as a prerequisite, but this is only required if you want passkeys registered against your own branded domain (e.g., “login.yourcompany.com”) in production.

For local testing, the sample works fine using the tenant’s default “ciam-tenant.ciamlogin.com” subdomain as the relying party — no custom domain purchase/verification needed.

Then:

• Install dependencies

npm install

• Start CORS proxy server

npm run cors

This starts the CORS proxy on http://localhost:3001.

* Start sample app

npm start

• Open your browser and navigate to:

https://auth.ciam-tenant.ciamlogin.com:3000

You see:

Click “Sign in”.

Sign in as normal. You will see:

Click “Add Passkey”.

1Password shows:

Save the passkey and then sign out.

Sign in again, and you see:

Click the saved passkey, and you are automatically signed in.

Neat 😃

Issue

While working through this sample, I hit a confusing error.

Signing in with a 1Password-synced passkey consistently failed with:

We couldn't sign you in. Your sign-in was successful but this passkey does 
not meet the criteria set by your admin. Try using another authentication 
method.

Checking the EEID sign-in logs showed a more specific failure:

Sign-in error code: 135016 Failure reason: FIDO sign-in is disabled via 
policy.

I worked through the usual suspects:

GET https://graph.microsoft.com/beta/policies/authenticationMethodsPolicy/
authenticationMethodConfigurations/Fido2

showed:

• state: enabled
• attestation enforcement off
• no key restrictions,
• passkeyTypes: “deviceBound, synced” both allowed
• “all_users” included

I thought it could be an authentication strength issue, but “Conditional Access authentication strengths” don't apply to EEID.

However, running the exact same sign-in flow in Chrome instead of Firefox fixed the problem!

This is most likely a Firefox/1Password WebAuthn compatibility gap rather than an Entra configuration issue.

All good!

Using passkeys with Entra External ID (EEID) was originally published in The new control plane on Medium, where people are continuing the conversation by highlighting and responding to this story.

The docs are here. The repo is here.

You can find my previous VI posts here.

You’ll find the VI tab in the EEID portal here:

For the quick start, you need a custom domain.

Note: Without a registered custom domain, there isn’t a supported Verified ID setup path for an external tenant.

Click the “Get started” button in the VI tab to complete setup in less than a minute.

The overview page shows:

Click “Try it now”.

You’ll be redirected to your “myaccount” page, and on that page, you will see:

Clicking that will show:

Click “Get ID”.

You’ll see:

On your mobile (assuming you already have Microsoft Authenticator), open the Authenticator app and tap “Verified IDs” in the bottom-right corner.

Click the “Scan QR” icon and scan the above QR code.

Then add the VI.

You will now see a “Verified Employee” VI in the list.

Back on the EEID VI overview page, click “Try it now” under “Use your new credential”.

You will see:

Click “Access discounts”. You see:

Click “Verify my Employee Credential”.

If you have multiple, select one.

Scan the QR code in the “Verified IDs” section as above.

Then you will see:

and your discount is applied.

Quick and neat!

All good!

Using Verified ID with Entra External ID (EEID) was originally published in The new control plane on Medium, where people are continuing the conversation by highlighting and responding to this story.

All the .http posts are here.

Several people have asked how to run the .http file I have been using to illustrate native auth flows in Entra External ID.

This assumes you are using Visual Studio.

• Open the .http file in Visual Studio (double-click it, or File > Open > File)
• No project/solution is required — .http files can be opened standalone
• Each request block has a “Send Request” link
• There is also a “Debug” link, which additionally launches/attaches the debugger for requests targeting your own local project — not applicable here since these requests target an Entra External ID tenant
• Click “Send Request” to execute a single request. The response (status,
  headers, body) opens in a separate tab/pane
• Variables are defined with “@name = value” and referenced with
  “{{name}}”
• Run the requests in sequence.
• Ensure you have set the variables:

@tenant = eeid tenant name e.g. contoso
@tenantDomain = contoso.onmicrosoft.com
@clientId = dd...b9
@username = some-user@company.co.nz
@password = some-password

All good!

How to run a .http file was originally published in The new control plane on Medium, where people are continuing the conversation by highlighting and responding to this story.

All the .http posts are here.

SSPR = Self-service password reset.

Read this post and this post first to get the background.

For this example, you need a user flow for email/password.

The .http file below is a continuation of the one in the post above.

This flow is more complicated because an OTP is sent to the email address, and a new password has to be entered, so you have to run the script in three parts:

• Run the start sign-in request
• Run the challenge request
• Get the OTP code sent to the email address
• Update the .http file for the OTP via @ssprOtpCode = some-code and save it
• Run the continue request
• Enter a new password in @newPassword (or do this beforehand)
• Run the submit request
• Run the poll_completion request. This is optional.

“Since updating of the user’s configuration with the new password incurs some delay, the app can use the /resetpassword/v1.0/poll_completion endpoint to poll Microsoft Entra for password reset status. The minimum amount of time in seconds that the app should wait between polling requests is returned from the /resetpassword/v1.0/submit endpoint in the poll_interval parameter.”

The submit request returns e.g.:

{
  "poll_interval": 2
}

The poll_completion request should return:

{
  "status": "succeeded"
}

If the status is something else and since “.http” files can’t loop automatically, just wait at least “poll_interval” seconds before manually clicking “Send request” on poll_completion again.

Check the request succeeded.

The script is:

###

### Native Auth Password SSPR

### Start sign up (SSPR)
# @name ssprStart
POST https://{{tenant}}.ciamlogin.com/{{tenantDomain}}/resetpassword/v1.0/start
Content-Type: application/x-www-form-urlencoded
Host: {{tenant}}.ciamlogin.com

client_id={{clientId}}&challenge_type=oob redirect&username={{username}}

###

### Challenge (SSPR) - triggers the email one-time passcode to be sent
# @name ssprChallenge
POST https://{{tenant}}.ciamlogin.com/{{tenantDomain}}/resetpassword/v1.0/
  challenge
Content-Type: application/x-www-form-urlencoded

client_id={{clientId}}&challenge_type=oob redirect&continuation_token=
  {{ssprStart.response.body.$.continuation_token}}

###

### <<< MANUAL STEP >>>
### Check email for the one-time passcode, then paste it below before running 
### Continue
@ssprOtpCode = 29563617

### Continue (SSPR) - redeem the OTP
# @name ssprContinue
POST https://{{tenant}}.ciamlogin.com/{{tenantDomain}}/resetpassword/v1.0/
  continue
Content-Type: application/x-www-form-urlencoded

client_id={{clientId}}&continuation_token={{ssprChallenge.response.body.$.
  continuation_token}}&grant_type=oob&oob={{ssprOtpCode}}

###

### <<< MANUAL STEP >>>
### Set the new password before running Submit
@newPassword = some-password

### Submit (SSPR) - submit the new password
# @name ssprSubmit
POST https://{{tenant}}.ciamlogin.com/{{tenantDomain}}/resetpassword/v1.0/
  submit
Content-Type: application/x-www-form-urlencoded

client_id={{clientId}}&continuation_token={{ssprContinue.response.body.$.
  continuation_token}}&new_password={{newPassword}}

###

### <<< OPTIONAL STEP >>>
### Poll Completion (SSPR)
# @name ssprPollCompletion
POST https://{{tenant}}.ciamlogin.com/{{tenantDomain}}/resetpassword/v1.0/
  poll_completion
Content-Type: application/x-www-form-urlencoded

client_id={{clientId}}&continuation_token={{ssprSubmit.response.body.$.
  continuation_token}}

###

Note: The URL and body lines are wrapped here for readability only.

An example of the email is:

Account verification code
To access eeid-tenant's apps and resources, please use the code below for 
account verification. The code will only work for 30 minutes.
Account verification code:
29184860

There is no token endpoint in the flow, so no JWTs are returned.

Refer to “How to run a .http file”.

All good!

Using the .NET .http file to test native auth with SSPR in Entra External ID (EEID) was originally published in The new control plane on Medium, where people are continuing the conversation by highlighting and responding to this story.

All the .http posts are here.

Read this post first to get the background.

For this example, you need a user flow for email/OTP.

The .http file below is a continuation of the one in the post above.

This flow is more complicated because an OTP is sent to the email address, so you have to run the script in two parts:

• Run the sign-in and challenge requests
• Get the OTP code sent to the email address
• Update the .http file for the OTP via @otpCode = some-code and save it
• Run the token request

### Native Auth OTP

@otpClientId = 61...9b
@otpUsername = user@gmail.com

### Start sign in (OTP)
# @name otpStartSignUp
POST https://{{tenant}}.ciamlogin.com/{{tenantDomain}}/oauth2/v2.0/initiate
Content-Type: application/x-www-form-urlencoded
Host: {{tenant}}.ciamlogin.com

client_id={{otpClientId}}&challenge_type=oob redirect&username={{otpUsername}}

###

### Challenge (OTP) - triggers the email one-time passcode to be sent
# @name otpChallenge
POST https://{{tenant}}.ciamlogin.com/{{tenantDomain}}/oauth2/v2.0/challenge
Content-Type: application/x-www-form-urlencoded

client_id={{otpClientId}}&challenge_type=oob redirect&continuation_token=
  {{otpStartSignUp.response.body.$.continuation_token}}

###

### <<< MANUAL STEP >>>
### Check email for the one-time passcode, then paste it below before running 
### the Token request
@otpCode = 29184860

### Token (OTP)
# @name otpToken
POST https://{{tenant}}.ciamlogin.com/{{tenantDomain}}/oauth2/v2.0/token
Content-Type: application/x-www-form-urlencoded

client_id={{otpClientId}}&continuation_token={{otpChallenge.response.body.$.
  continuation_token}}&grant_type=oob&scope=openid offline_access
  &oob={{otpCode}}

###

Note: The body lines are wrapped here for readability only.

An example of the email is:

Account verification code
To access eeid-tenant's apps and resources, please use the code below for 
account verification. The code will only work for 30 minutes.
Account verification code:
29184860

The result is:

{     
  "token_type": "Bearer",
  "scope": "openid profile email 00000003-0000-0000-c000-00...00/User.Read",
  "expires_in": 4539,
  "ext_expires_in": 4539,
  "access_token": "ey...7w",
  "refresh_token": "1.A...v5M",
  "id_token": "ey...mA"
}

A full set of JWTs is returned.

Refer to “How to run a .http file”.

All good!

Using the .NET .http file to test native auth with email/OTP in Entra External ID (EEID) was originally published in The new control plane on Medium, where people are continuing the conversation by highlighting and responding to this story.

All the .http posts are here.

The .http docs are here.

The native auth docs are here.

Read this for more background.

A “.http” file is a plain-text file supported natively by the VS HTTP client editor (also compatible with the VS Code REST Client extension format) that lets you define, organise, and execute HTTP requests directly from your IDE — without needing external tools like Postman or curl.

In a .NET project, it’s commonly scaffolded automatically alongside ASP.NET Core Web API projects, giving you a ready-made way to exercise your API’s endpoints during development.

I have been using Postman to test the API, but when I created another native auth project, I decided to try the .http method.

As stated above, this is now part of the project. I don’t need to use Postman.

My .http file to test EEID sign-in via native auth with username and password looks like:

@BasicApi_HostAddress = http://localhost:5216

### Native Auth Password
@tenant = eeid tenant name e.g. contoso
@tenantDomain = contoso.onmicrosoft.com
@clientId = dd...b9
@username = some-user@company.co.nz
@password = some-password

### Start sign up
# @name startSignUp
POST https://{{tenant}}.ciamlogin.com/{{tenantDomain}}/oauth2/v2.0/initiate
Content-Type: application/x-www-form-urlencoded
Host: {{tenant}}.ciamlogin.com

client_id={{clientId}}&challenge_type=password redirect&username={{username}}

###

### Challenge
# @name challenge
POST https://{{tenant}}.ciamlogin.com/{{tenantDomain}}/oauth2/v2.0/challenge
Content-Type: application/x-www-form-urlencoded

client_id={{clientId}}&challenge_type=password redirect&continuation_token=
  {{startSignUp.response.body.$.continuation_token}}

###

### Token
# @name token
POST https://{{tenant}}.ciamlogin.com/{{tenantDomain}}/oauth2/v2.0/token
Content-Type: application/x-www-form-urlencoded

client_id={{clientId}}&password={{password}}&continuation_token=
  {{challenge.response.body.$.continuation_token}}
  &grant_type=password&scope=openid offline_access

###

Note: The body lines are wrapped here for readability only.

In VS, it looks like:

To send the “Start sign up” request, just click “Send request”.

This displays:

in a separate tab.

The “continuation_token” is then passed to the next request. You have to run the requests in the correct order.

“{{startSignUp.response.body.$.continuation_token}}” is a variable expression that VS resolves at request-send time, right before the request is transmitted.

This:

• Looks up the named request (`startSignUp`) in the in-memory response cache
• Reads its “response.body”
• Applies the JSONPath “$.continuation_token” to extract the value from the JSON response
• Substitutes the resolved value into the request body/headers/URL wherever the “{{…}}” placeholder appears

The end result of the “Token” request is:

{
  "token_type": "Bearer",
  "scope": "profile openid email 00000003-0000-0000-c000-00...00/User.Read",
  "expires_in": 3773,
  "ext_expires_in": 3773,
  "access_token": "ey...eg",
  "refresh_token": "1....Vg",
  "id_token": "ey...7g"
}

Clicking the “Debug” link starts the project under the debugger (if not already running) and immediately fires this request, so breakpoints are hit.

There’s a lot more functionality, e.g environments and secrets — refer to the docs above.

Refer to “How to run a .http file”.

All good!

Using the .NET .http file to test native auth in Entra External ID (EEID) was originally published in The new control plane on Medium, where people are continuing the conversation by highlighting and responding to this story.

The repo is here.

“This repository contains samples demonstrating how to use Agent Identities in Microsoft Entra ID with .NET. Agent Identities enable AI agents to securely access downstream services using either autonomous (app-only) or user-delegated tokens”.

“Agent Identities are a new capability announced at Ignite 2025 in Microsoft Entra ID that enable AI agents to:

• Autonomous Agent Identity — Acquire app-only tokens for operations that don’t require user context.
• Agent User Identity — Acquire tokens with user context for operations requiring user identity (e.g., sending emails, participating in Teams channels)”

The Learn article on agent ID is here.

Essentially, you define blueprints that contain agent IDs, each with a sponsor and an owner for auditability.

In the repo, there is a /scripts directory.

.\Setup-EntraIdApps.ps1 -TenantId ae...3b -OutputFormat UpdateConfig

This produces:

========================================
Entra ID Agent Identity Blueprint Setup
Customer Service Agent Sample
========================================

Instance Prefix: CustomerServiceSample-

[INFO] Checking Microsoft Graph connection...
[INFO] Not connected to Microsoft Graph. Connecting...
[SUCCESS] Connected to tenant: ae...3b
[INFO] Current user: rory@entra-tenant.onmicrosoft.com (will be set as 
  SponsorUserId)

--- Step 1: Creating Agent Identity Blueprint ---

[INFO] Using specialized Agent Identity Blueprint endpoint...
[INFO] Creating Agent Identity Blueprint application: 
  CustomerServiceSample-Orchestrator
[INFO] Creating Agent Identity Blueprint using beta endpoint...
[SUCCESS] Successfully created Agent Identity Blueprint
[INFO] Blueprint Application ID: 2a..4d
[INFO] Blueprint App ID (Client ID): 2a..4d
[WARNING] Could not create Agent Identity Blueprint using API. Falling back 
  to standard application.
[WARNING] Error: The property 'scopes' cannot be found on this object. 
  Verify that the property exists.
[INFO] Checking for existing app: CustomerServiceSample-Orchestrator
[SUCCESS] Found existing app: CustomerServiceSample-Orchestrator 
  (ClientId: 2a...4d)

--- Step 5: Creating Service Principal for Blueprint ---

[INFO] Creating service principal for blueprint...
Making request to create service principal for Agent Blueprint: 
  System.Collections.Hashtable.Orchestrator.ClientId
[SUCCESS] Service principal created successfully

--- Step 2: Adding Client Secret to Blueprint ---


--- Step 3: Creating Downstream Service Applications ---

[INFO] Processing service: CustomerServiceSample-OrderAPI
[INFO] Checking for existing app: CustomerServiceSample-OrderAPI
[INFO] Creating new app: CustomerServiceSample-OrderAPI
[SUCCESS] Created app: CustomerServiceSample-OrderAPI 
  (ClientId: 18...73)
[INFO] Configuring API scopes...
[INFO] Setting Application ID URI: api://18...73
[SUCCESS] Adding scope: Orders.Read
[INFO] Updating OAuth2 permission scopes...
[SUCCESS] API scopes configured successfully
[INFO] Configuring app roles...
[SUCCESS] Adding app role: Orders.Read.All
[INFO] Updating app roles...
[SUCCESS] App roles configured successfully
[SUCCESS] Service CustomerServiceSample-OrderAPI configured successfully

[INFO] Processing service: CustomerServiceSample-ShippingAPI
[INFO] Checking for existing app: CustomerServiceSample-ShippingAPI
[INFO] Creating new app: CustomerServiceSample-ShippingAPI
[SUCCESS] Created app: CustomerServiceSample-ShippingAPI 
  (ClientId: b2...7f)
[INFO] Configuring API scopes...
[INFO] Setting Application ID URI: api://b2...7f
[SUCCESS] Adding scope: Shipping.Read
[SUCCESS] Adding scope: Shipping.Write
[INFO] Updating OAuth2 permission scopes...
[SUCCESS] API scopes configured successfully
[SUCCESS] Service CustomerServiceSample-ShippingAPI configured successfully

[INFO] Processing service: CustomerServiceSample-EmailAPI
[INFO] Checking for existing app: CustomerServiceSample-EmailAPI
[INFO] Creating new app: CustomerServiceSample-EmailAPI
[SUCCESS] Created app: CustomerServiceSample-EmailAPI 
  (ClientId: 35...65)
[INFO] Configuring API scopes...
[INFO] Setting Application ID URI: api://35...65
[SUCCESS] Adding scope: Email.Send
[INFO] Updating OAuth2 permission scopes...
[SUCCESS] API scopes configured successfully
[SUCCESS] Service CustomerServiceSample-EmailAPI configured successfully


--- Step 4: Configuring Inheritable Permissions for Blueprint ---

[INFO] Setting up inheritable permissions to downstream APIs...
[INFO] Configuring inheritable permissions for Agent Identity Blueprint...
[INFO] Creating service principal for: CustomerServiceSample-OrderAPI
[INFO] Creating service principal for: CustomerServiceSample-ShippingAPI
[INFO] Creating service principal for: CustomerServiceSample-EmailAPI
Successfully added inheritable permissions to Agent Identity Blueprints
Permissions are now available for inheritance by agent blueprints

--- Step 6: Granting Admin Consent for Inheritable Permissions ---

[INFO] Granting admin consent for orchestrator app...
[SUCCESS] Admin consent granted successfully


========================================
Setup Completed Successfully!
========================================


--- Updating Configuration Files ---

[INFO] Setting SponsorUserId to current user: 
  rory@entra-tenant.onmicrosoft.com (5c...64)
[INFO] Detected tenant domain: entra-tenant.onmicrosoft.com
[INFO] Updating: C:\...\ms-identity-agent-identities\
  dotnet\CustomerServiceAgent\src\AgentOrchestrator\appsettings.json
[SUCCESS] Updated successfully
[INFO]
Configuring client secret using User Secrets...
Successfully saved AzureAd:ClientCredentials:0:ClientSecret to the secret 
  store.
[SUCCESS] Successfully configured client secret in User Secrets
[INFO] The secret is stored securely outside of source control
[INFO] For production, use Azure Key Vault or environment variables
[INFO] See SECRETS-MANAGEMENT.md for detailed instructions

[INFO] Updating: C:\...\ms-identity-agent-identities\dotnet\
  CustomerServiceAgent\src\AgentOrchestrator\AgentOrchestrator.http
[SUCCESS] Updated TenantName to: entra-tenant.onmicrosoft.com
[INFO] Updating: C:\...\ms-identity-agent-identities\dotnet\
  CustomerServiceAgent\src\DownstreamServices\EmailService\appsettings.json
[SUCCESS] Updated successfully
[INFO] Updating: C:\...\ms-identity-agent-identities\dotnet\
  CustomerServiceAgent\src\DownstreamServices\OrderService\appsettings.json
[SUCCESS] Updated successfully
[INFO] Updating: C:\...\ms-identity-agent-identities\dotnet\
  CustomerServiceAgent\src\DownstreamServices\ShippingService\appsettings.json
[SUCCESS] Updated successfully
[SUCCESS]
All configuration files updated!

--- Next Steps ---

[INFO] 1. Review the configuration values above
[INFO] 5. Verify the updated appsettings.json files
[INFO] 6. Build and run the solution: 
  dotnet run --project src/CustomerServiceAgent.AppHost
[INFO] For detailed setup instructions, see: docs/setup/02-entra-id-setup.md
DeletedDateTime Id    AppRoleId     CreatedDateTime
--------------- --    ---------     ---------------
                6t...Bc 4a...14 25/08/2026 3:25:53 am

This creates a blueprint (under the Agents tab).

Note: This blueprint is contained under the “Agents” tab in the portal rather than the classic app registrations list view, but it is backed by a standard application object underneath.

The blueprint establishes the “kind” of agent and records metadata shared across all agent identities of a common kind.

The blueprint tab looks like:

with me as the owner and sponsor:

and the permission:

If you click on “Credentials”, you see a client secret.

This is the secret created at the end of the script.

The secret is stored using .NET User Secrets.

To see the secrets:

PS C:\...\ms-identity-agent-identities\dotnet\CustomerServiceAgent\src\
AgentOrchestrator> dotnet user-secrets list
AzureAd:ClientCredentials:0:ClientSecret = 27...ak

In the blueprint, if you click on agent identities:

you see:

and if you click on “agent identity1”:

you see an agent identity that points back to the blueprint.

Each agent ID has a corresponding agent user.

If you click on “View agent’s user account”, you see the agent's user account:

If you click on “View” next to “Agent identity's access”, you see the permissions:

These correspond to the app registrations:

Each of these is an API that the orchestrator calls.

If you look at OrderAPI e.g., you see under “Expose an API”:

The script also configures the appsettings.json:

{
  "Logging": {
    "LogLevel": {
      "Default": "Information",
      "Microsoft.AspNetCore": "Warning",
      "Microsoft.Identity": "Debug"
    }
  },
  "AllowedHosts": "*",
  "AzureAd": {
    "Instance": "https://login.microsoftonline.com/",
    "TenantId": "ae...3b",
    "ClientId": "2a...4d",
    "ClientCredentials": [
      {
        "SourceType": "ClientSecret"
      }
    ],
    "CallbackPath": "/signin-oidc"
  },
  "AgentIdentities": {
    "AgentIdentity": "YOUR_AGENT_IDENTITY_ID",
    "AgentUserId": "YOUR_AGENT_USER_ID",
    "SponsorUserId": "5c...64"
  },
  "DownstreamApis": {
    "OrderService": {
      "BaseUrl": "https://localhost:7001",
      "Scopes": [
        "api://18...73/.default"
      ]
    },
    "ShippingService": {
      "BaseUrl": "https://localhost:7003",
      "Scopes": [
        "api://b2...7f/.default"
      ]
    },
    "EmailService": {
      "BaseUrl": "https://localhost:7004",
      "Scopes": [
        "api://35...65/.default"
      ]
    },
    "MicrosoftGraph": {
      "BaseUrl": "https://graph.microsoft.com/v1.0",
      "Scopes": "User.Read Mail.Send ChannelMessage.Send"
    }
  }
}

So what we have is:

• An Agent Orchestrator service that acts as the AI agent, creating an “agent blueprint,” an autonomous agent identity, and an agent user identity
• Calls to multiple downstream APIs (Order, Shipping, Email) using either app-only or delegated tokens depending on the operation
• .NET Aspire used for orchestration plus distributed tracing/logging, so you can visually observe how each downstream call’s identity/token flow works via the Aspire dashboard
• In-memory stores, so it runs without external dependencies (aside from Entra ID app registrations)
• The AgentOrchestrator.http file is used to manually exercise the flow: first call api/agentidentity to create/get an agent identity, then use that identity’s GUID to call api/customerservice/process, which triggers the orchestrator to call the downstream APIs on behalf of the agent

The .http file looks like:

“Send request” is a hyperlink that executes the request.

So it's similar to Postman.

Run the sample. You should see the Aspire portal:

The URLs won’t work because the services are just API. There is no website.

You can use this to inspect the traces if there are issues.

In the .http file, click “Send request” for the top call:

/api/agentidentity

You should see:

{
  "agentIdentity": {
    "@odata.type": "#Microsoft.Graph.AgentIdentity",
    "displayName": "agent identity1",
    "agentIdentityBlueprintId": "2a...4d",
    "id": "54...58",
    "sponsors@odata.bind": null,
    "owners@odata.bind": null
  },
  "agentUserIdentity": {
    "@odata.type": "#microsoft.graph.agentUser",
    "displayName": "agentuser1",
    "userPrincipalName": "agentuser1@entra-tenant.onmicrosoft.com",
    "id": "3f...70",
    "identityParentId": "54...58",
    "mailNickname": "agentuser1",
    "accountEnabled": true
  },
  "adminConsentUrlScopes": "https://login.microsoftonline.com/
    ae...3b/v2.0/adminconsent?client_id=54...58&
    scope=api%3A%2F%2F...65%2FEmail.Send%20api%3A%2F%2F...73
    %2FOrders.Read%20api%3A%2F%2F...7f
    %2FShipping.Read%20api%3A%2F%2F...7f%2FShipping.Write
    &redirect_uri=https://entra.microsoft.com/TokenAuthorize&state=xyz123",
  "adminConsentUrlRoles": "https://login.microsoftonline.com/
    ae...3b/v2.0/adminconsent?client_id=54...58
    &role=api%3A%2F%2F...73%2FOrders.Read.All
    &redirect_uri=https://entra.microsoft.com/TokenAuthorize&state=xyz123"

Now copy the agentIdentity ID (“54…58”) into the @AgentIdentity line in the .http file (as per the image above) and save.

Then in the browser, execute the two HTTPS URLs above (“adminConsentUrlScopes” and “adminConsentUrlRoles”) in separate tabs. I was logged on as a GA for these.

Then grant permission on all the screens by clicking “Allow" e.g.

and:

There are a few of these.

Now click “Send request” for the second call:

/api/customerservice/process

You should see:

{
  "orderId": "12345",
  "status": "Completed",
  "orderDetails": {
    "orderId": "12345",
    "customerId": "C001",
    "productName": "Enterprise Software License",
    "quantity": 10,
    "price": 9999.99,
    "status": "Processing",
    "orderDate": "2026-08-23T03:34:10.3914844Z"
  },
  "customerHistory": null,
  "deliveryInfo": {
    "orderId": "12345",
    "trackingNumber": "TRK-UPDATED-2E109F08",
    "status": "Updated by Agent",
    "carrier": "Express Delivery",
    "estimatedDelivery": "2026-08-26T03:34:10.4442694Z",
    "shippingAddress": "Updated via orchestration"
  },
  "emailSent": true,
  "teamsMessagePosted": false,
  "messages": [
    "Fetching order details using agent identity...",
    "Order 12345 retrieved successfully",
    "Updating delivery info using agent user identity...",
    "Delivery info updated successfully",
    "Sending email notification using agent user identity...",
    "Email notification sent successfully",
    "Customer service request processed successfully"
  ]
}

The email notification is just a dummy. No actual email is sent.

The flow uses two OIDC grant types:

“client_credentials” for the Autonomous Agent Identity (app-only)

and:

“urn:ietf:params:oauth:grant-type:user-fic” (user Federated Identity Credential) — for the Agent User Identity

In the agent Identities model, an agent Identity doesn’t get its own manually managed client secret or certificate.

Instead, it trusts its parent blueprint application to vouch for it. This trust relationship is the Federated Identity Credential — the agent identity is federated to its parent.

In a diagram:

Blueprint App (Application object, the Orchestrator)
│ (agentIdentityBlueprintId reference)
▼
Agent Identity (Service Principal, type = Microsoft.Graph.AgentIdentity)
│ (identityParentId reference)
▼
Agent User Identity (also created via Graph, linked to the Agent Identity)

For more FIC details, refer to this and this and this.

An example of the client credentials JWT is:

{
  "aud": "api://18...73",
  "iss": "https://sts.windows.net/ae...3b/",
  "iat": 1787629639,
  "nbf": 1787629639,
  "exp": 1787633539,
  "aio": "k2...YA",
  "appid": "54...58",
  "appidacr": "2",
  "idp": "https://sts.windows.net/ae...3b/",
  "oid": "54...58",
  "rh": "1.A...AA.",
  "roles": [
    "Orders.Read.All"
  ],
  "sub": "54...58",
  "tid": "ae...3b",
  "uti": "4E...AA",
  "ver": "1.0",
  "xms_ftd": "WR...1z"
}

An example of the FIC JWT is:

{
  "aud": "api://35...65",
  "iss": "https://sts.windows.net/ae...3b/",
  "iat": 1787629642,
  "nbf": 1787629642,
  "exp": 1787633951,
  "acr": "0",
  "aio": "AZ...4V",
  "appid": "54...58",
  "appidacr": "2",
  "ipaddr": "www.xxx.yy.zzz",
  "name": "agentuser1",
  "oid": "3f...70",
  "rh": "1.A...AA.",
  "scp": "Email.Send",
  "sid": "007...3b7",
  "sub": "Mx...00",
  "tid": "ae...3b",
  "unique_name": "agentuser1@entra-tenant.onmicrosoft.com",
  "upn": "agentuser1@entra-tenant.onmicrosoft.com",
  "uti": "P_8...cAA",
  "ver": "1.0",
  "xms_ftd": "2LS...21z"
}

In table form:

This maps directly to the pattern demonstrated in the sample:

• reads use the autonomous (app-only) agent identity via “client_credentials”
• writes that must be attributed to a specific user use the agent user identity via the “user-fic” grant

Note: I tried to get the sample working with Entra External ID (EEID), but although the script runs without issues and EEID does have an Agents tab in the portal, I get errors like:

• IDX10214: Audience validation failed. See https://aka.ms/identitymodel/app-context-switches
• Error: AADSTS500208: The domain is not a valid login domain for the account type

I cannot find any references confirming whether agents and agentic IDs are supported in EEID.

All good!

Using the Entra ID Agentic ID sample was originally published in The new control plane on Medium, where people are continuing the conversation by highlighting and responding to this story.