Ping Identity Developer Portal Blog

Hardening the handoff: a pattern for app-to-web single sign-on

Wed, 08 Apr 2026 00:00:00 GMT

This post was originally published on Medium.

We’ve all been there, haven’t we? That shiny mobile app that you’ve just downloaded from your favourite brand, the one that’s offered you a really clean and modern sign in experience (without browser hand-offs, perhaps even using a passkey for quick login), suddenly and inexplicably spits you out into a browser view when you tap a particular button or menu item. Hybrid apps — those that combine both native and web elements — are an unavoidable reality for many organisations (and their users) as they look to balance time to market on new features with ever-stretched engineering budgets and the technical debt further down the stack that they’ve never quite managed to pay off.

As identity professionals who care about that delicate balance between user experience and security, the question that comes up time and again is this: what is the best way to secure these apps? How do I ensure a slick user authentication process at the start and then safely re-use that session across all aspects of my application, when some parts of it are delivered via browser or web-view? In this article, I’ll explore the challenges that these hybrid app models present to us and propose a workable solution based on modern identity standards (with a sprinkling of identity orchestration). The solution I describe below has been built and tested using Ping Identity’s PingOne SSO identity provider together with the PingOne DaVinci identity orchestration engine.

Eager for the punchline? Here’s the succinct summary for those on a time and attention budget!

The session transfer problem

Before we can start to solve the challenges that we face in securing hybrid mobile applications, we should start by better defining the problem space. For the purposes of this discussion, we define a hybrid mobile application as a native application running on a mobile device where certain portions of the application’s functionality are delivered via a web browser or web view on the device — that is to say, the app is not fully native. The exact specifics of how and when the app switches context between a native delivery versus a browser-based delivery of functionality are not important, however there are two requirements that we must fulfil, namely

access to the browser-based content requires an authenticated user session (presumably in the form of a browser session cookie, which is how these things have always been done)
the user has already performed authentication in order to access the app itself and as such should not be prompted to re-authenticate in order to access the browser-based content.

A number of follow-on points are salient here and those who have grappled with this situation in the past are no doubt familiar with them. The most important ones are, perhaps, as follows:

In a native application context, the authenticated user session is typically represented by an OAuth access token, issued to the application by a trusted Authorisation Server in response to a user login.
There are established best practices for how a native application should go about obtaining such a token by leveraging the Auth Code Flow with PKCE via the system browser. This approach is battle-hardened and peer-reviewed and should always be the first alternative considered when building a user authentication process for a native app.
To directly contradict the previous point, however, many (if not most) digital product owners and UX designers find the experience trade-off unacceptable and thus strongly resist using a browser-delivered authentication ceremony within the context of a native application, preferring to use fully native SDKs to interact directly with the authentication service to obtain the necessary access token.
Whichever approach is selected for initial user authentication, the basic requirement is the same in terms of providing a single-sign-on experience if the app includes hybrid web content; in order for the user to access said content without re-authentication, there needs to be a session cookie present in the browser at the time that content is requested. This is the most basic requirement (the sine qua non, if you will) without which the user is guaranteed to be prompted for repeat authentication

All this talk of cookies is possibly making you hungry by now, but we do need to explore the intricacies just a little deeper before taking a well-earned coffee break! This problem really is all about cookies, though — that much we cannot deny. One would think and would hope that the pattern of using the system browser to obtain authentication credentials from the user in the first place would create a session cookie in that browser as a serendipitous side effect (and give us a further piece of ammunition in convincing our product owner and UX colleagues to eschew a fully-native alternative). In practice, however, this approach has been shown to be non-deterministic at best, if not downright flaky, due to the somewhat arcane and seemingly ever-changing rules regarding cookie persistence and visibility across browser tabs and invocations. Without going into all of the details, I think it is sufficient to say that, based on the experiences of many doing this work in the field today, we cannot assume that a session cookie set during initial login will be available during subsequent browser-based interactions. The reasons for this are all very well-meant; examples being Apple’s Intelligent Tracking Prevention feature and Google’s equivalent Privacy Sandbox work — designed to increase user privacy. As a result, even if we are lucky enough to stumble upon a configuration on a given device that does give us the cookie visibility that we need, there is every chance that further tightening of cookie rules in the future could break our solution, leaving both product owners and (more importantly) end users furious.

What we are left with is a challenge to solve, broadly defined as follows:

“how, then, do we engineer a mechanism where the access token that represents the logged-in user within the native context can be used to create a browser session cookie at the point that the user needs to access web content”

It goes without saying that any such mechanism MUST be secure and avoid exposing us and our users to malicious theft of tokens, user sessions and the applications and API’s that these protect.

A standards-based pattern for secure session transfer

We know that we need a mechanism whereby we can take the app’s representation of an authenticated user session, the OAuth access token, and turn this into an authenticated session in a web browser, in the form of a session cookie. OAuth does not provide a standardised pattern or grant type that we can use to solve this problem and as a result a number of approaches have emerged, many of which fall down on either user experience or security, and sometimes both.

A naive approach to the problem would be to launch a new OAuth authorisation request in the browser via the Auth Code flow, and simply pass the app’s access token directly to the Authorisation Server as a custom URL parameter. This does imply that whatever OAuth Server implementation is in use must provide the capability to extract the access token from the query string, validate it and create a web session cookie for the subject of the token. While not many implementations that I’ve encountered will provide this sort of “access-token-to-web-session” mechanism out of the box, most will offer some sort of customisation capability, via plug-in or extension script that will allow such a mechanism to be built.

I would advise against this approach for a number of reasons, with the most critical being the security risk that it carries.

We must remember, at all times, the inherent security challenge implied by the Bearer Token model, where simple possession of an access token grants whoever holds the token full power to use it. We should assume that any access token issued to a native application client would be a powerful artefact indeed and allow a malicious actor the ability to invoke any API on the application back-end should they manage to obtain it. Adding such a dangerous object to a URL query string and sending it out “into the wild” where it could almost trivially be intercepted is not the solution we seek.

The alternative approach that I recommend is to use a relatively-recent addition to the OAuth family of standards to achieve the same outcome in a way that provides better protection of the access token during the session transfer process, namely OAuth 2.0 Pushed Authorization Requests (or PAR), described in RFC 9126. To set the scene, let’s look at the abstract of the document that describes the approach:

“This document defines the pushed authorization request (PAR) endpoint, which allows clients to push the payload of an OAuth 2.0 authorization request to the authorization server via a direct request and provides them with a request URI that is used as reference to the data in a subsequent call to the authorization endpoint.”

To paraphrase and simplify, PAR allows us to provide our sensitive access token directly to the Authorisation Server via a direct HTTPS Post from our native app code, rather than including it as an insecure query string parameter in the browser. This separation of data payloads between the “back channel” (direct POST) and the “front channel” (browser GET) significantly improves the security baseline of what we need to achieve and provides solid scaffolding for the further work we need to do.

An additional advantage to the approach is that PAR gives us a ready-made query string parameter, in the form of the returned request_uri, that is guaranteed to be single-use and short-lived, thus reducing the very large attack surface that the alternative approach inherently creates.

I mentioned further work above, and it is important to realise that while PAR does provide a great starting point, it is not the complete solution to this challenge by itself. There is more to be done both in terms of user experience and also security, which we’ll explore in the next section. For now, though, let’s describe the “bones” of the approach here, in the form of a worked example

Alice opens the Acme Inc native application and clicks the “Login” button. She is authenticated via a native authentication experience (no browser pop-up) that results in a valid OAuth access token being sent to the app. The app responsibly and securely stores this access token on her behalf.
Alice clicks the “Manage My Profile” button in the app. Acme Inc delivers profile management via an embedded browser view within the app, and the web backend that serves this content requires a session cookie in order to identify Alice and link her to the correct profile.
When Alice clicks the button, native app code retrieves her access token and initiates a secure POST to the Acme Inc Authorisation Server’s PAR Endpoint. The post body includes access token as a custom parameter, in addition to client_id, scope and all the other required OAuth parameters. In accordance with the PAR standard, the Authorisation server returns a response including a request_uri, a single use value that acts as a reference to the request data that has been provided.
The native app code now opens a browser window, passing in the URL of the Acme Inc Authorisation Server’s authentication endpoint, with the request_uri from the previous step as a parameter. The Authorisation Server uses identity orchestration to validate the provided access token and create a web session for Alice, before redirecting her to the profile management application, where the browser cookie now ensures a single-sign-on experience

The informed reader will, of course, have many remaining questions based on the above explanation. Let’s address them now.

Enabling secure session transfer on top of PAR

Native applications are public clients from an OAuth point of view. Put another way using language extracted directly from RFC6749, “it is assumed that any client authentication credentials included in the application can be extracted”. The implications of this reality are far reaching and many of them beyond the scope of this discussion, but it matters here because it means we cannot use a confidential client (with a client secret) to kick off our PAR request from inside the app.

It is important to realise here that we are not using PAR for its ability to complete an end-to-end flow, that ends with a redirection and ultimate token issuance to the same OAuth client that initiated the request. We are rather using PAR as a way to initiate a browser flow and then build on the side effect of the session cookie that is created. This means that we do not, in fact, want to ever complete the flow that we start via PAR. We only want to go as far as creating a session cookie before we break out and redirect the user to the actual application, which will start its own Auth Code flow from scratch, using its own client_id, redirect_uri, PKCE enforcement, etc.

The combination of the two factors above suggests that we should configure and use a specific OAuth Client as a sort of session transfer proxy — that is, a completely new client unrelated to either the native app that starts the transfer or the web app that ultimately benefits. We should take as many precautions as we can to lock down this session transfer client such that it can only be used for a single purpose, but also we should be sure not to add any configurations to our existing clients that could weaken their existing security posture.

Let’s describe the flow again, adding the additional details that we have described above.

Alice clicks the “Manage my profile” button in the app. The app code starts the PAR process using the client_id of the dedicated Session Transfer Client. It includes a scope such as “session_transfer” in the request, and generates a PKCE Code Challenge that it includes with the request. Note that the corresponding Code Verifier can be discarded at this point since this flow is not intended to ever result in an access token issuance.
The app code includes three other pieces of information (at minimum). These are the access token that it already holds for the user, the IP address that it is using, and the URL of the profile management application.
It sends the PAR request to the authorisation server and obtains a response that contains a request_uri, which it appends to the AS’s authorization endpoint URL before opening a browser tab to initiate the front-channel flow.
When the front-channel request hits the Authorisation Server, the request is validated (to ensure it has not expired or already been used) before being handed to the identity orchestration engine for further processing.
The orchestration engine (as above, I have tested this with PingOne DaVinci, mileage may vary if using a different platform) must introspect or validate the provided access token to ensure that it is valid, has not expired and was indeed issued to the expected client (the mobile app). It should also compare the IP address provided as part of the PAR request to the IP address passed via the current HTTP request, to ensure that the backend and frontend requests come from the same place. Further checks can be implemented using orchestration logic as required.
Should the above checks succeed, the orchestration engine extracts the “sub” claim from the access token to determine the appropriate user, and sets a session cookie in the browser for that same user.
At this point, the orchestration logic simply redirects the browser to the URL of the profile management application (the same URL that was provided via the PAR back-channel initiation in step 3). This is the step that interrupts the flow started by the Session Transfer Client and ensure that no auth code or access token is ever issued.
The profile management application now receives the browser redirect and is responsible for initiating its own OAuth/OpenID Connect Auth Code flow, just as it would had a browser opened the app URL directly. It should generate its own redirect to the AS, including its own client_id and redirect_uri, its own appropriate scopes and its own PKCE Code Challenge. The AS will start a user authentication process that should complete with no further user interaction required, based on the presence of the session cookie set in step 6.
The browser is thus redirected back to the profile management application with everything that is needed to display logged-in user content.

TL;DR

My good friend and proof-reader Gransomeuk pointed out that some folks will just want the take away, rather than the full three course meal. With his help, here’s the summary, with a nifty sequence diagram to match.

Phase 1 (Back-Channel): The mobile app passes the highly sensitive access token directly to the Authorization Server over a secure connection (POST). In return, it gets a short-lived reference string (request_uri). This solves the problem of putting the Access Token in a visible URL query string.
Phase 2 (Front-Channel): The app opens the browser using only the reference string. The Identity Orchestration engine (e.g., PingOne DaVinci) verifies that the person in the browser is the same person who holds the app token (by checking IP addresses, etc) and drops a session cookie in the browser.
Phase 3 (SSO): The browser is redirected to the target Web Application. Because the cookie now exists, the Web App can sign the user in automatically via standard OpenID Connect without asking the user to type in a password again.

“Next time on…”

In the interests of keeping things digestible, I will publish two follow up articles in the coming weeks.

The first will explore the technical implementation of this pattern end-to-end, using PingOne SSO and PingOne DaVinci, together with a simple Android application to show it all working.

The second will dive a little deeper into some of the security implications of this approach, highlight the advantages, point out a number of inherent drawbacks and also suggest further steps that can be taken to harden the implementation.

References and further reading

We Rebuilt the PingOne API Docs. Here’s What’s New.

Wed, 01 Apr 2026 00:00:00 GMT

Introduction

If you build integrations, you probably spend a lot of time staring at API documentation. So when we decided to overhaul the PingOne API docs, our goal was simple: get out of your way and make it easier for you to actually test and write code.

The new site officially went live in early January. Here’s a quick rundown of what changed and how to use the new features.

It’s a lot faster and easier to navigate

The most obvious improvement is performance. The site loads faster, the pages are lighter, and the layout now matches the rest of the Ping Identity documentation ecosystem.

We also reorganized the navigation so you don’t have to dig through endless menus to find helpful information:

New to PingOne? We have plenty of resources to help you get up and running quickly. Jump into our Getting Started guide, explore Foundations, or follow along with step-by-step tutorials in the Use Case Library.
Learn about APIs: You can dive straight into the PingOne Platform SSO or Auth APIs to see detailed info on all endpoints, which are logically grouped by functional area.
Universal services: These now have their own dedicated section, making it clearer how they fit into the wider Ping Identity portfolio.
Smart search: If you still can’t find what you need, the search bar now uses the same AI-assisted backend as our other doc sites.

Test endpoints in your browser

For every endpoint, you’ll see example requests and responses in multiple programming languages. More importantly, we completely rebuilt the Try Request feature:

Live testing: Plug in your parameters, hit the button, and get real API responses back immediately.
Persistent parameters: You no longer have to copy and paste the same environment or user IDs over and over. Your parameters carry over from one API call to the next. This includes access tokens, so you don’t have to constantly re-authenticate.
Secure local storage: To keep things safe, those variables only live in your web browser’s session storage. The second you close the tab, they’re gone.

Update your bookmarks

To keep things simple, all developer-focused content, including cloud and on-premise APIs, now lives in one place: the Developer Portal.

Check out the new PingOne API docs at developer.pingidentity.com/pingone-api.

Let us know what you think

This launch was a massive effort, but the work doesn’t stop here. Documentation is never really “finished.”

Give the new site a spin. If you run into a weird bug, see a typo, or have any suggestions, let us know by clicking the feedback icon in the top-right corner of each page.

Happy coding!

Next steps

Visit our new PingOne API documentation.
Check out developer resources for all Ping Identity products at developer.pingidentity.com.
Join the discussion on the Ping Identity Developer Community.

Securing MCP Servers with Ping’s MCP Gateway

Wed, 01 Apr 2026 00:00:00 GMT

You’ve been shipping MCP servers and each one comes with its own OAuth handler, its own scope-checking logic, its own audit hooks. Security code that should be administered centrally ends up copy-pasted across every server you build.

The MCP security gateway capabilities in PingGateway solve this by acting as a security bouncer in front of your MCP servers. The bouncer checks credentials at the door, enforces the rules, and logs everything — so your servers never have to.

You can find a deeper dive into MCP’s architecture, workflow, and security model in the Ping Identity MCP documentation.

Where PingGateway sits as your MCP security gateway

In a typical setup, PingGateway as an MCP security gateway sits between the MCP client (the AI agent) and your MCP server.

What PingGateway adds for MCP servers

By fronting your MCP server, PingGateway validates that requests are syntactically correct MCP, enforces operational requirements like audit and throttling, enforces authorization of the request, and mediates security tokens before forwarding to the MCP server.

Your server continues to implement tools and domain behavior; the gateway provides the surrounding security and operational controls.

What capabilities does PingGateway provide?

PingGateway extends its proven API security stack with MCP-aware capabilities you configure once and reuse across every server:

McpValidationFilter: Validates Origin / Accept headers and MCP / JSON‑RPC format and populates an McpContext so subsequent filters (throttling, policy, metrics) can inspect method and tool names.
McpProtectionFilter: Serves OAuth 2.0 Protected Resource Metadata (/.well-known/oauth-protected-resource/...) on behalf of your MCP endpoint, ensures the access token’s aud matches the configured resourceId and uses PingGateway’s OAuth 2.0 resource server capabilities to validate tokens and enforce scopes.
McpAuditFilter: Emits MCP‑specific audit events (who called which tool, where, and with what result)
MCP metrics: Exposes Prometheus metrics per MCP method/tool (counts, latencies, errors).
MCP throttling: Rate limits access per route, per tool, per client or per identity.

Seeing it in action: the “unauthenticated” request

The gateway’s job is to stop what shouldn’t get through — and wave through what should. If the MCP client (AI agent) sends a request without the proper identity tokens required by the Ping Identity platform, the gateway will block it.

The situation: missing authorization header.

An AI agent sends a tool call without an Authorization header:

POST /mcp/v1/call_tool

{
  "method": "tools/call",
  "params": {
    "name": "access_customer_database",
    "arguments": {
      "customer_id": "12345"
    }
  }
}

Result: 401 Unauthorized — rejected by PingGateway before the request ever reaches your server.

With valid credentials, the gateway allows the request through.

The same agent retries with a valid, scoped Bearer token:

POST /mcp/v1/call_tool
Authorization: Bearer <valid-access-token>

{
  "method": "tools/call",
  "params": {
    "name": "access_customer_database",
    "arguments": {
      "customer_id": "12345"
    }
  }
}

Result: 200 OK — PingGateway validates the token, confirms scope, logs the event, and forwards the request to your MCP server. Your server never saw the first request at all.

Benefits for the MCP server developer

MCP security shouldn’t be implemented in each MCP server’s codebase
Without a gateway, each MCP server grows its own OAuth, scopes, auditing, throttling, and risk logic.
With MCP Security Gateway, a standard PingGateway route in front of each MCP server centralizes that logic; you reuse the pattern for every new server.
Comply with MCP authorization by configuration, not code
MCP requires OAuth 2.0 Protected Resource Metadata so agents know which AS to use and which resource they call. PingGateway serves this metadata and validates tokens according to it, so you configure security once instead of coding it per server.
Gain observability “for free”
Audit logs and metrics at the gateway show which tools are used, by whom, and how often, without extra instrumentation in your MCP code.
Protect MCP servers from noisy or malicious agents
Central throttling and policy/risk rules ensure your servers only see pre‑validated, rate‑limited, authorized requests.
Integrate legacy or sensitive backends cleanly
Use token mediation at the gateway to map agent tokens to whatever your backends expect (different scopes, JWT formats, API keys, mTLS), keeping your MCP server’s backend calls simple and aligned with existing security models.

The gateway acts as the “bouncer,” ensuring the server only spends resources processing requests that are properly formatted, authenticated, and authorized.

Get started!

The MCP security gateway tutorial walks you through the complete setup. Download the sample MCP agent and server (or bring your own), insert PingGateway in front of your MCP server, and enable MCP processing and authorization in the gateway configuration.

MCP exposes your business capabilities to AI agents. PingGateway makes sure only the right agents — with the right credentials and the right permissions — ever reach them.

Next steps

Get started with the MCP security gateway tutorial.
Visit the MCP documentation on the Ping Identity developer portal.
Check out developer resources for all Ping Identity products at developer.pingidentity.com.
Join the discussion on the Ping Identity Developer Community.

Introducing the PingOne Advanced Identity Cloud (AIC) MCP Server

Tue, 31 Mar 2026 00:00:00 GMT

Developers have already discovered that LLMs (such as Claude, Gemini, GPT, Grok, and others) accelerate workflows across coding, debugging, and operations. A real breakthrough has been the ability to create custom agents within the IDE. Now developers can write specialized agent workflows that combine reasoning, tooling, and domain logic to solve problems autonomously.

To help these agents work effectively, we need a bridge between the AI and your actual services. That is where MCP (Model Context Protocol) comes in.

Today, we are excited to introduce the AIC MCP Server. This tool connects your PingOne Advanced Identity Cloud (AIC) environment directly to the AI agents you use every day in IDEs like Cursor, VS Code, and GitHub Copilot, or command-line tools like Claude Code and Gemini CLI.

What Exactly is an MCP Server?

Think of the Model Context Protocol (MCP) as a universal remote for AI. In the past, every AI platform had to build its own unique way to talk to different databases or services. MCP changes that by creating a standard “contract.”

It allows an AI agent to see a list of available tools, understand what they do, and know exactly how to call them. When you use an MCP server, you aren’t just giving an AI a window into your data; you’re giving it a specialized “hand” to perform tasks for you.

You can find a more detailed look into MCP’s architecture, workflow, and security model in the Ping Identity MCP documentation.

How the AIC MCP Server Works

PingOne Advanced Identity Cloud (AIC) is Ping Identity’s modern, single-tenant identity platform. It manages users, authentication flows, roles, policies, audit logs, and customer-facing themes. If you’re running an identity operation, AIC is where the configuration lives.

The AIC MCP server is an open-source TypeScript tool, distributed through npm, which exposes 40+ tools that wrap AIC’s REST APIs and packages them as MCP-compatible functions. Instead of manually navigating the console or hand-crafting API requests, you describe what you want in natural language. Your agent translates that to the right MCP tools, the MCP server handles the API calls and authentication, and returns results that the agent can reform into natural language.

Here’s the practical difference:

Task	Without MCP	With AIC MCP Server
Find failed logins from 9 PM – 11 PM yesterday	20 minutes (console navigation, log filtering, export)	1 minute (“Show me authentication failures from 9 PM – 11 PM yesterday”)
Create a new role with specific permissions	15 minutes (console form, multi-step workflow)	2 minutes (“Create a role called product-admin with these permissions: …”)
List all users in a specific group	10 minutes (API docs, construct request, parse response)	30 seconds (“Which users are in the engineers group?”)

Why This Matters: MCP Adoption Is Evolving

MCP has become the standard for AI-to-infrastructure integration. Popular developer tools (such as Claude Desktop, Cursor, GitHub Copilot, VS Code, Gemini CLI) all now support MCP. Developers are moving from being software engineers or technical admins to being agent orchestrators.

Identity and access management (IAM) is a perfect fit for AI assistance. Configuration can be repetitive. Audits demand detailed log parsing. Bulk operations can be tedious. Configuration updates may take a while when navigating multiple screens and modals in the web console. IAM is also not an isolated capability, often connected to other systems that benefit from being managed as a group. In this way, MCP clients allow connection of multiple MCP servers from different providers to bridge multi-service, multi-product workflows. The more systems connected, the more autonomy an agent has, the more the user can delegate.

For developers, this means faster operations. Less manual console navigation. Less copying and pasting IDs between tabs. Reduced context-switching.

Core Capabilities: 35+ Tools Across Five Categories

The AIC MCP server exposes 35+ tools organized into five functional areas:

Managed Objects: Perform “search, create, and update” tasks for users, roles, groups, and organizations. (for example, “Find all users with an @acme.com email.”)
Themes & Branding: Update your login pages, logos, and brand colors across different regions programmatically.
Logging & Audits: Query activity logs by time, user, or error type—perfect for quick security check-ups.
Secrets & Variables: Securely manage API keys and environment variables without having to hard-code them.
Authentication Journeys: Build and test complex login flows (journeys) and the scripts that power them.

The server exposes many tools providing broad capability, with every action authenticated using OAuth 2.0 with PKCE and tied to your user identity in the audit log.

Getting Started: Hands-On Walkthrough

Getting the AIC MCP Server running takes 5 minutes. You’ll need:

A Sandbox or Development AIC tenant.
Node.js 18+ on your machine (or Docker).
An MCP-compatible AI client (Claude Desktop is recommended).
5 minutes of setup time.

Step 1: Configure Your MCP Client

Find your AIC tenant’s base URL in the console (for example, my-tenant.forgeblocks.com). Then add the configuration to your MCP client’s config file:

{
  "mcpServers": {
    "aic-mcp-server": {
      "type": "stdio",
      "command": "npx",
      "args": ["-y", "@ping-identity/aic-mcp-server"],
      "env": {
        "AIC_BASE_URL": "your-tenant.forgeblocks.com"
      }
    }
  }
}

Replace your-tenant.forgeblocks.com with your actual tenant URL (no https:// prefix).

Step 2: Authenticate

Restart your AI client. When you first use a tool, the server will:

Open your browser to your AIC login screen.
Ask you to log in with your AIC admin credentials as an administrator.
Show you the permissions the server needs (scopes like fr:idm:\*, fr:idc:monitoring:\*).
After you’re authenticated, securely save your token in your OS keychain (where available).

This is a one-time setup for the session. The token stays in your keychain and can be reused until expiry or ephemerally if using the Docker image. Subsequent tool calls reuse the cached token, if it is still valid.

Step 3: Make Your First Tool Call

Count all users in the system and show me the total.

Behind the scenes, your agent will:

Understand the available tools provided by the MCP server.
Call the listManagedObjects tool to discover object types.
Call queryManagedObjects to fetch users.
Return the count in plain English.

Expected response: “There are 247 users in your AIC tenant.”

Real-World Use Case: Debugging Authentication Issues

It’s 8 AM. A high-priority bug report just landed: “A recent change to the primary user authentication journey has caused failures in overnight tests.” You need to:

Analyze the bug and map it to the existing auth journey.
Provision test identities that match the specific failure criteria.
Trace the logs to find the exact line of code or configuration causing the break.
Patch the journey and verify the fix immediately.

Without the server: 45 minutes of context switching (Jira, documentation, console, log aggregators, scripts).

With the AIC MCP Server (and other MCP servers that interact with ticket systems and UX):

1. Analyze the Bug and Journey

Your prompt to Claude:

Read bug report AUTH-802 and show me the current 'SSO-Onboarding' journey configuration.  Compare with recent closed tickets that may have caused a breaking change.

The Action: Your agent fetches the ticket details using the ticket system MCP server and pulls the journey configuration. It identifies a probable failure that happens during a user lookup step from an external data source. Time to insight: 30 - 60 seconds.

2. Reproduce with Test Users

Your prompt to Claude:

Create three test users: two with valid metadata in the external data source and one with invalid data to replicate the reported error.

The Action: Agent calls createManagedObject and tools related to the external data source. It returns key details for fresh accounts tailored to your debugging needs. Result: Environment ready in 20 seconds.

3. Trace Logs & Identify the Root Cause

Your prompt to Claude:

Run a test authentication for the user with invalid data. Show me the logs and highlight any stack traces.

The Action: Agent triggers a mock login and calls queryLogs. Result: “Found an error relating to user lookup. The journey isn’t handling user lookup where there is invalid data correctly.” Time to discovery: 5 minutes.

4. Update & Re-test

Your prompt to Claude:

Update the 'SSO-Onboarding' journey to include appropriate error handling when user data lookups fail, then re-test with the same user.

The Action: Agent calls saveJourney with the fix and re-runs the authentication trace. Result: “Test passed. Redirect successful. Journey updated in Dev environment.”

Total time saved: 30 - 45 minutes of manual work → less than 10 minutes of natural language queries. The workflow can be packaged up into an agent to save more time later. The difference compounds across your team.

Security and Caveats

OAuth 2.0 Authentication

Every tool call is authenticated with your AIC credentials using OAuth 2.0 (PKCE flow). Your password is never stored. The resulting access token is saved securely in your OS keychain—the same place your browser stores credentials.

Audit Trail

All actions—queries, creates, updates, deletes—appear in your AIC audit log tied to your user identity and are traceable as MCP-based interactions. There’s full traceability for compliance and security reviews.

Sandbox and Development Only

Currently, the server works with Sandbox and Development AIC tenants only. Production support is on the roadmap. This ensures you can safely experiment and iterate without risk to live systems.

Agent Permissions

Only use the MCP server with AI agents you trust. The agent has the same permissions as your authenticated user. If you’re an AIC admin, the agent is an admin. Always review agent prompts and tool calls before deploying them to production workflows.

Open Source

The server is Apache 2.0 licensed and open-source on GitHub. Review the code, audit the dependencies, and contribute. The entire codebase is at github.com/pingidentity/aic-mcp-server.

Next Steps: Try It Today, Give us Feedback

Run your first agent workflow.
Consider your developer workflows, how can the MCP server be used to turn repetitive or menial tasks into automated, intelligent workflows?
Share your use cases and workflows with the Ping Identity developer community.
If you find issues or would like to see enhancements, raise an issue on the code repository. We’re listening!

The AIC MCP Server is in early release. Your feedback shapes what comes next!

References

GitHub Repository: https://github.com/pingidentity/aic-mcp-server
NPM Package: https://www.npmjs.com/package/@ping-identity/aic-mcp-server
PingOne AIC Documentation: https://docs.pingidentity.com/pingoneaic/
Model Context Protocol (MCP) Specification: https://modelcontextprotocol.io/specification/2025-11-25
OAuth 2.0 PKCE (RFC 7636): https://tools.ietf.org/html/rfc7636

Introducing the PingOne MCP server

Tue, 31 Mar 2026 00:00:00 GMT

Introduction

Developers building applications using PingOne eventually hit the same friction point. Application code is in the IDE, while application configuration, audit logs, policies, and user journey flows are managed in the web console.

That context switch is the problem, not the task itself. Registering an application in PingOne or spinning up a new environment for development is straightforward. The cost is the frequent interruption leading to a break in flow, tab switching, and copying and pasting IDs.

Although frequent switching between IDE and the web console has been well accepted over the years, the expectations of application developers is shifting. Application developers are shifting to AI tools and agentic development practices. Generative code experiences such as VS Code Copilot, Claude Desktop, Claude Code, Gemini CLI, and GPT Codex are changing the ways that developers interact with their application code, and they’re changing the way developers interact with online services.

The PingOne MCP Server reduces the gap. It connects your PingOne tenant directly to MCP-compatible generative AI IDEs and CLIs. Instead of leaving your editor, you describe what you need from your application integration in natural language, and your agent handles the PingOne API calls, returns the IDs and configuration details you need, and lets you keep iterating on application code.

This isn’t about replacing the PingOne console for operational work. It’s about making identity platform configuration a first-class citizen of the development cycle, available in the same context where you write code, run tests, and ship features.

What Is MCP?

System configuration living outside the development cycle isn’t unique to PingOne. But it’s a fundamental challenge in building agentic systems: how do AI agents and IDE AI chat systems connect to the external services they need to act on?

The Model Context Protocol (MCP), originally developed by Anthropic, provides a specification for the interactions between AI systems (the abstract world of “intent”) and today’s systems (the concrete world of deterministic input/output). Before MCP, every integration between an AI agent and an external tool required custom code—bespoke connectors, point-in-time maintenance, duplicated effort across teams. MCP standardizes the connection layer, providing a “USB style” connector interface so that any MCP-compatible client (VS Code Copilot, Claude Desktop, Cursor, and others) can discover and invoke any MCP server’s capabilities using a common protocol, without needing custom code on either side.

In practical terms, an MCP server currently exposes three types of capabilities:

Tools (executable actions the agent can invoke)
Resources (contextual data to inform reasoning)
Prompts (templated workflows)

The agent discovers tools at runtime, selects what it needs, and calls them through JSON-RPC messages. Prompts and resources are loaded at the user’s request.

You can find a deeper dive into MCP’s architecture, workflow, and security model in the Ping Identity MCP documentation.

What is the PingOne MCP Server?

The PingOne MCP Server implements the MCP standard for PingOne’s Management API, exposing 14 tools across 4 capability areas, and represents the start of the journey in producing useful tools to accelerate developer workflows.

In practical terms: your AI agent in your IDE can now interact with your PingOne tenant the same way it interacts with your filesystem, your terminal, or your version control. It becomes part of the same conversation as your application code.

The initial set of tools cover what developers need most when building on PingOne:

Applications: List, retrieve, create, and update OIDC/OAuth 2.0 applications
Environments: List, retrieve, create, and update PingOne environments; manage services (such as MFA and DaVinci)
Populations: List, retrieve, create, and update user populations
Directory: Generate per-day identity trend reports.

All operations execute as the authenticated user and are logged in PingOne’s audit trail. The agent never sees your access tokens or sign-on credentials; the MCP server handles authentication entirely, returning only the data the agent needs.

Missing something you need? Get in touch! Raise an enhancement request on the code repository. Your feedback helps drive what we do next.

Getting Started: From Zero to First Tool Call

To get started you need a PingOne account (Try Ping here), an MCP-compatible client (VS Code with Copilot, Cursor, Claude Desktop, or similar).

For the adventurous, in your favourite agent IDE, try:

Help me install and configure the PingOne MCP server from github.com/pingidentity/pingone-mcp-server

Otherwise, follow the instructions below.

1. Install the Server

The easiest path on macOS or Linux is Homebrew:

brew tap pingidentity/tap
brew install pingone-mcp-server

Verify:

pingone-mcp-server --version

For Windows, the MCP server is built as an executable file, ready to download from the project releases. See the project README for full details for Windows installation and other options.

2. Set Up a Worker Application in PingOne

The server needs credentials. Create a worker application in your PingOne tenant:

Sign on to the PingOne Administration Console.
Open the environment for your Administrator users.
Go to Applications > Add (+).
Name it (for example, “PingOne MCP Server”) and choose type Worker.
Go to Configuration and configure OAuth 2.0 settings:
- Set response type to Code.
- Set grant type to Authorization Code.
- Set PKCE Enforcement to S256_REQUIRED.
- Enable Refresh Token.
- Set redirect URI to http://127.0.0.1:7464/callback
- Set the Token Endpoint Authentication Method to None
Save and capture your Environment ID and Client ID from the application details.
Finally, remember to enable the MCP server application!

Although the example here uses the ‘Authorization Code’ grant type, ‘Device Code’ is also available. You can find more details in Setting Up PingOne Worker Applications for MCP Server.

3. Configure Your MCP Client

Once installed, add the server to your MCP client’s configuration. For VS Code with Copilot Chat:

{
  "servers": {
    "pingOne": {
      "type": "stdio",
      "command": "pingone-mcp-server",
      "args": [
        "run"
        // "--disable-read-only" // uncomment to enable write tools
      ],
      "env": {
        "PINGONE_MCP_ENVIRONMENT_ID": "your-environment-id-uuid",
        "PINGONE_AUTHORIZATION_CODE_CLIENT_ID": "your-client-id-uuid",
        "PINGONE_ROOT_DOMAIN": "pingone.com"
      }
    }
  }
}

If your tenant is in a different region, use pingone.ca, pingone.eu, pingone.com.au, pingone.sg or pingone.asia

To install to other IDEs, including Claude Code, Gemini and Cursor, refer to the project README.

That’s it. On first tool use, your browser opens your PingOne administrator sign-on page. After you authenticate with your admin credentials, the server caches your token securely in your OS keychain (where available) or is cached ephemerally. Every subsequent tool call validates and reuses the same token.

Real-World Use Case: Prepare an Environment for App Development

You’re building a new application feature that requires its own isolated identity configuration: a dedicated, ephemeral sandbox environment, a test user population, and an OIDC application for the OAuth flow your code will use.

Without the MCP server, you stop coding, switch to a browser, walk through the PingOne console to create the environment, toggle the services you need, create the population, register the application, copy the client ID and environment ID back into your project, and resume back.

With the PingOne MCP Server, you stay in your IDE:

Note that write tools must be enabled using --disable-read-only at startup.

Step 1 — Understand what already exists:

"List my PingOne sandbox environments and show me which services are enabled in each."

The agent calls list_environments and returns a structured overview. You can see your existing dev and staging environments, what’s running in each, and confirm there’s no overlap with what you’re about to create.

Step 2 — Create the new environment:

"Create a new sandbox environment called 'feature-payments-dev'.
Enable the MFA and DaVinci services."

The agent calls create_environment, then update_environment_services to add MFA and DaVinci, and returns the environment ID. You paste it into your .env file without leaving the editor.

Step 3 — Create the test population:

"Create a population called 'Payments Test Users' in the
feature-payments-dev environment."

The agent calls create_population. Returns the population ID. You add it to your test harness configuration inline.

Step 4 — Register the OIDC application:

"Create an OIDC application in feature-payments-dev called
'Payments App'. Use authorization code grant with PKCE enforced.
Redirect URI is http://localhost:3000/callback."

The agent calls create_oidc_application with the correct grant type, PKCE settings, and redirect URI. It returns the client ID.

Step 5 — Confirm and move on:

"Give me a summary of the feature-payments-dev environment:
environment ID, enabled services, population name and ID,
and the Payments App client ID."

The agent returns a clean summary, and you’re ready to move on. The entire flow took less than three minutes without switching context once. All four operations are in your PingOne audit log, associated with your user identity.

The process can be wrapped into a skill or an agent, and the rest of the team can benefit from the workflow.

Security Considerations

The most important thing to understand about the PingOne MCP Server’s security model: the agent is acting as you. The MCP server doesn’t have its own service account, its own permissions, or its own audit identity. When the agent calls a PingOne API through the MCP server, it calls it as your authenticated user account. Everything it does is bounded by the PingOne roles assigned to your admin account and actions are visible in the audit log, attributable to your identity.

Other features include:

Production environment restrictions. By default, all write actions are disabled on production environments. This is to protect against accidental or unintended configuration changes, even if your user has the ability to make changes to production configuration.

Write operations require an explicit decision when starting the MCP server. Running the server without --disable-read-only exposes only read tools. This is to allow you to explicitly opt in to write tools on your tenant.

Full audit trail. Every API call from the server includes a session ID and transaction ID in the request headers. You can trace any change back to the MCP server session through PingOne’s audit log.

Preview software. This is an early release. APIs and behavior may change. Use caution when using the MCP server against important environments. Found a bug? Open an issue.

Open source. Apache 2.0 licensed. Read the code, audit the dependencies, contribute a fix: github.com/pingidentity/pingone-mcp-server.

Next Steps: Try It Today, Give us Feedback

The current 14 tools cover a subset of what developers may need when developing on PingOne. But the goal is broader: PingOne configuration should be as accessible from your IDE as your database schema, your API spec, or your CI/CD pipeline. Manual steps you need to take between your code and your identity configuration is a point of friction that can be improved upon.

Near-term additions include Docker support for containerized workflows and simplified installation, expanded tool coverage across more PingOne APIs, and support for upcoming MCP specification changes as the standard evolves.

The roadmap is shaped by what you actually need. If there’s a specific tool or capability that would close a gap in your workflow, raise an enhancement request or start a discussion in the repository.

Get a PingOne trial account if you don’t have one.
Install and follow the project README.
Think about the identity configuration steps in your current developer workflow. Where does context-switching slow you down?
Share what you build with the Ping Identity community.

Your feedback shapes what comes next. Try it today and give us feedback on what you want to build.

References

PingOne MCP Server code repository: https://github.com/pingidentity/pingone-mcp-server
PingOne MCP Server releases: https://github.com/pingidentity/pingone-mcp-server/releases
PingOne documentation: https://docs.pingidentity.com/pingone/latest/
Model Context Protocol (MCP) specification: https://modelcontextprotocol.io/specification/2025-11-25
PingOne Management API: https://apidocs.pingidentity.com/pingone/platform/v1/api/
OAuth 2.0 PKCE (RFC 7636): https://tools.ietf.org/html/rfc7636
Homebrew Tap: https://github.com/pingidentity/homebrew-tap

Rapidly Deploying PingGateway with PingOne Advanced Identity Cloud (P1AIC)

Tue, 03 Mar 2026 00:00:00 GMT

This post was originally published on Medium.

Note: This blog applies to PingGateway versions from 2025 onwards. For earlier PingGateway (IG) releases, please refer to the original blog here.

Introduction

Integrating applications securely and efficiently with PingOne Advanced Identity Cloud (P1AIC) is a common requirement for developers and architects exploring modern identity platforms.

This article demonstrates how to deploy PingGateway in standalone mode and protect a sample application using Cross-Domain Single Sign-On (CDSSO) with P1AIC — all via a single automation script.

The objective is straightforward:

Enable new users to quickly stand up PingGateway, integrate it with P1AIC, and understand how CDSSO protection works end-to-end.

This deployment is designed for:

Learning and enablement
Proof-of-concept environments
Developer experimentation
Workshops and demonstrations

It is not intended as production use.

The repository containing all assets and the deployment script is located here on GitHub.

To get straight to deploying go here.

Scenario

“As a new customer, I want to understand PingGateway through hands-on experimentation — specifically how to configure it to protect an application via CDSSO with P1AIC.”

This blog walks through that exact scenario.

What the Script Deploys

The repository includes:

install_ping_gateway_P1AIC.sh — automation script
admin.json.HTTPS
admin.json.HTTP_ONLY
static-resources.json
cdsso-idc.json

When executed, the script provisions:

A PingGateway standalone instance
A Sample Application
Route configurations that:
- Reverse proxy static resources
- Protects /home/cdsso via CDSSO with P1AIC

All components are deployed on the same host for simplicity.

Architecture Overview

PingGateway runs in Standalone Mode, meaning:

It does not require deployment into a servlet container.
It runs directly from the extracted ZIP.
It uses Vert.x internally to provide its runtime engine.

The result is a lightweight, fast-starting gateway instance suitable for development and experimentation.

The end-to-end flow looks like this:

User accesses protected resource via PingGateway.
PingGateway checks for a valid OIDC token.
If no valid token is present, the browser is redirected to P1AIC.
User authenticates with P1AIC.
P1AIC redirects back to PingGateway.
PingGateway validates the token and grants access to the sample application.

This demonstrates CDSSO in action, and described in more details below:

To learn more about CDSSO check out this link

Script Execution

Step 1 — Download Assets aond Configure Networking

Download the ZIP from GitHub here.
Down the PingGateway Standalone ZIP and PingGateway Sample Application JAR from here and place both files in the same directory as the script.
By default PingGateway will be deployed against this host pinggateway.test.com and the Sample app to sample.test.com. Add both to your /etc/hosts file. For example for IP 172.168.1.10 the hosts entry will look like this:

172.168.1.10 pinggateway.test.com sample.test.com

Step 2 — Configure the Script

Modify lines 11–30 in the install_ping_gateway_P1AIC.sh script to match your environment

Step 3 — Configure P1AIC

Create a Test User

Log in to P1AIC.
Select the appropriate realm.
Navigate to Identities → Manage.
Create a new user.

Create a Gateway Agent

Navigate to Gateways and Agents.
Click New Gateway/Agent.
Select Identity Gateway.
Enter the following and hit Save:
- Agent ID (e.g. pinggateway_agent_cdsso)
- Password

Ensure these values match the script configuration:

AGENT_ID
AGENT_SECRET

Configure Redirect URIs

HTTPS:

https://pinggateway.test.com:9443/home/cdsso/redirect

HTTP:

http://pinggateway.test.com:9000/home/cdsso/redirect

Step 4 — Execute the Script

For P1AIC deployments, use HTTPS mode due to SameSite cookie requirements:

Run: ./install_ping_gateway_P1AIC.sh https
For standalone PingAM deployments run ./install_ping_gateway_P1AIC.sh http

Step 5 — Validate Deployment

After deployment, access:

https://pinggateway.test.com:9443/home/cdsso.

You should be redirected to P1AIC for authentication. Upon successful login, the Sample Application page will be displayed.

Note: If you were already logged into P1AIC during setup, log out first or use a private browser window to prevent cookie conflicts.

Step 6— Stop/Start the

To stop/start PingGateway and the Sample App use:

Stop Services: ./install_ping_gateway_P1AIC.sh stop
Start Services: ./install_ping_gateway_P1AIC.sh start

Script Breakdown

The script performs the following high-level steps.

1. Environment Validation

The script validates:

PingGateway ZIP is present
Sample Application JAR is present
Required commands are available (unzip, curl, etc.)
The host can connect to the configured P1AIC endpoint

Execution stops if validation fails.

2. Clean Installation Handling

If a previous installation exists:

PingGateway is stopped
The sample application is stopped
The installation directory is removed

This ensures clean redeployment.

3. PingGateway Deployment

The script:

Extracts the PingGateway ZIP
Performs a temporary start/stop cycle to initialise directories
Creates required configuration folders

PingGateway is deployed in Production Mode by default.

4. Script Execution Mode

The script supports:

https mode (recommended for P1AIC)
http mode (for standalone PingAM deployments)

When HTTPS mode is selected, a self-signed certificate is generated automatically.

Note — Self-signed certificates are for demonstration only and should not be used in production.

5. Sample Application Deployment

The sample application is deployed locally and started on the configured ports, providing a target application for PingGateway to protect.

6. Route Configuration

Two routes are created:

static-resources.json — Allows PingGateway to proxy static resources (e.g., CSS) without authentication. This improves performance and mirrors real-world deployment patterns.
cdsso-idc.json — Protects the /home/cdsso context. It checks for a valid OIDC id_token, redirects unauthenticated users to P1AIC, validates tokens on return and grants access upon successful validation

Conclusion

This script provides a fast, repeatable way to deploy PingGateway locally and integrate it with PingOne Advanced Identity Cloud using CDSSO — all within minutes. It enables you to:

Deploy PingGateway in standalone mode
Understand how standalone runtime operates
Explore CDSSO behaviour with P1AIC
Observe complete end-to-end authentication flows

By simplifying setup and automating the foundational configuration, this approach accelerates learning and removes friction from experimentation. It serves as an ideal starting point for:

Developers building familiarity with PingGateway
Architects validating integration patterns
Technical enablement sessions and workshops

Most importantly, it provides a clear, structured baseline from which you can extend into more advanced routing logic, security hardening, certificate management, and production-ready deployment patterns.

In short, this script turns what could be a multi-step manual configuration process into a streamlined, educational experience — helping you move from exploration to implementation with confidence.

Securing High-Risk Actions: Transactional Authorization over REST

Wed, 26 Nov 2025 00:00:00 GMT

This post was originally published on Medium.

Introduction

Requiring a user to explicitly authorise access to a sensitive resource every time they attempt to access it is a common security requirement. A typical example is in financial services, where initiating a payment might trigger a one-time passcode (OTP) sent to the user’s device, or a push notification requiring approval. These additional steps increase friction intentionally, ensuring the user is genuinely present and consenting before a high-risk action is allowed.

In the PingOne Advanced Identity Cloud (P1AIC) and PingOne Advanced Identity Software (self-managed PingAM), this capability is known as Transactional Authorisation (TAuthZ). You can read more about it here.

The most common and recommended architecture for enabling Transactional Authorisation is to use a Policy Enforcement Point (PEP) such as PingGateway or the PingAgent, which interact with P1AIC or PingAM as the Policy Decision Point (PDP). Another pattern is to implement enforcement directly in applications via the Ping SDKs (JavaScript, iOS and Android).

However, some customers who operate their own application gateways prefer to interact directly with the PDP REST APIs. This blog focuses on that third approach and provides a clear, end-to-end example using an automated shell script to demonstrate how the REST flow works.

The high-level sequence of events for both application-based and gateway-based integrations is broadly the same. It’s explained in detail here, but here’s the simplified flow:

Use Case

In this blog, we demonstrate a REST-based approach to Transactional Authorization (TAuthZ) using an automated shell script. The scenario covers a high-risk operation — accessing an example makePayment API
(https://api.bankingexample.com:443/makepayment) via an HTTP POST request.

The script performs the following steps:

Authenticate the user using a standard login journey and obtain an SSO token
Authenticate an admin using an admin-specific login journey in order to access the policy endpoint, issuing an SSO token with extended session durations (for example, a 60-minute idle and max time) so the client can cache it and improve performance.
Calls the policy evaluation endpoint to request access to the protected makePayment API.
Receive a policy advice with a TransactionConditionAdvice (TxId) from the PDP instructing the client to execute a Transactional Authorization journey (for example, OTP or push approval).
Executes the required TAuthZ journey with this TxId, collecting and completing the necessary callbacks for the one-time step-up authentication flow.
Resubmits the policy evaluation request, now including the completed transactional context and TxId.
Finally, receives a one-time authorization decision granting access to the sensitive API.

This demonstrates how applications or gateways can interact directly with the PDP REST APIs to enforce secure, single-use authorization for high-risk operations.

Solution

Let’s get building 💪

All assets are located here.

Import the Journeys

For this example we’ll import three journeys:

NormalLogin — Used to simulate a standard user login.
AdminLogin — Used to simulate admin login with extended session timeouts.
TransactionalAuthZLogin — Used as the step-up authentication journey triggered by the TAuthZ policy.

Download the journey export from here.
From the P1AIC Platform UI, navigate to Journeys on the left panel > Click Import > Take a Backup if required > Select Browse > Locate and open the file from step 1 > Click Next > Start Import

Once the import is complete, the three new journeys will appear as shown below. Note that the TransactionalAuthZLogin journey should be a strong MFA journey. However, a simplified version has been used here for clarity in this blog.

Import the Transactional Authorization Policy

Download the policy XML file from here.
From the P1AIC Platform UI, expand Native Consoles > Click Access Management > Expand Authorization > Click Policy Sets.
Click Import Policy Sets > Find the XML file from step 1 > Click Open
Refresh the browser and the new transactionalAuthZ Policy Set will appear.
Clicking into it will show the makePayment policy as shown below where:
- The resource is defined as https://api.bankingexample.com:443/makepayment
- The allowed action is HTTP POST.
- The subject is set to AuthenticatedUsers
- The Transaction Environments condition targets the TransactionalAuthZLogin journey.

Create the Test Users and Apply Privileges

From the P1AIC Platform UI, Expand Identities > Click Manage > New Alpha realm — user > Create a user with the following:
- Username: policy_user
- Firstname: Policy
- Lastname: User
- Email Address: policy_user@example.com
- Password: !!_SeCu4E@Pa55w04D$
Repeat Step 1 but this time for the policy admin user:
- Username: policy_admin
- Firstname: Policy
- Lastname: Admin
- Email Address: policy_admin@example.com
- Password: !!_Adm1nSeCu4E@Pa55w04D$
From the Access Management Native Console, navigate to Identities > Groups tab > Add Group > Set the Group ID to policy_admin > Create.
Add the policy_admin user as a member and hit Save.
From the Privileges tab, enable Entitlement Rest Access and hit Save Changes.

Execute the Script

Now that we have all the configuration in place, let’s bring it to life with the script.

Download the script from here
Modify the AM_URL to match your environment
Execute the script to demonstrate the flow

The output will look this like:

./transactional_authZ_DS.sh  
Getting cookie name  
CookieName is: XXXX
*********************  
Creating end-user SSO token for user: policy_user  
End-user SSO token is: ZER7HY8OL...
*********************  
Creating policy-admin SSO token for user: policy_admin  
Policy-admin SSO Token is: o0jzAU....
*********************  
Calling transactional policy: transactionalAuthZ  
Transaction Condition Advice Id is: 195b8505-3dba-4bbc-a71a-7debed2c2596
*********************  
Calling ../authenticate endpoint with Transaction Condition Advice Id: 195b8505-3dba-4bbc-a71a-7debed2c2596 to get callbacks
*********************  
Completing callbacks for submission  
Completed callback payload:  
{  
"authId": "eyJ0eXAiOiJKV1QiLC....74",  
"callbacks": [  
....
*********************  
Calling authenticate endpoint with advice and completed callbacks  
{  
"tokenId": "ZER7HY8O....IwMQ..*",  
"successUrl": "/enduser/?realm=/alpha",  
"realm": "/alpha"  
}
*********************  
Finally, calling policy endpoint post transactional AuthZ with Transactional Conditional Advice Id of: 195b8505-3dba-4bbc-a71a-7debed2c2596  
[  
{  
"resource": "https://api.bankingexample.com:443/makepayment",  
"actions": {  
"POST": true  
},  
"attributes": {},  
"advices": {},  
"ttl": 0  
}  
]
*********************

Conclusion

Transactional Authorization (TAuthZ) is a powerful capability within PingOne Advanced Identity Cloud (P1AIC) and PingAM, enabling organisations to enforce strong, step-up authentication precisely at the moments where risk is highest. Whether approving a financial transaction, confirming a high-value action, or validating a user’s intent, TAuthZ offers a reliable way to introduce friction only when it truly matters.

This blog illustrates how to execute a complete Transactional Authorization flow entirely over REST. By walking through user authentication, admin token retrieval, policy evaluation, TxId handling, step-up journey execution, and final policy re-evaluation, we showed how an application or custom gateway can interact directly with the PDP — while still leveraging the full power and flexibility of PingAM’s decisioning capabilities.

Smarter “Remember Me” with PingOne Protect

Tue, 21 Oct 2025 00:00:00 GMT

This post was originally published on Medium.

Introduction

In the world of Identity and Access Management (IAM), it’s always a balancing act between security and user experience. Organisations want to introduce just the right amount of friction, at the right moment, and in the right context to protect users without disrupting them. The goal is to maintain a seamless, trusted customer journey while minimising drop-off and frustration.

To achieve this, many businesses have implemented a “Remember Me” capability within their web channels. Once a user successfully signs in, subsequent visits allow them to be logged in automatically without re-entering their credentials — a familiar and convenient feature which is especially common in retail environments.

However, “Remember Me” in isolation has its flaws. While it delivers convenience, it often lacks the intelligence to adapt when the context changes. For example, what if a user originally authenticates from the UK but suddenly appears to log in from Singapore — an impossible traveller scenario? What if their IP address shifts unexpectedly, the login occurs at an unusual time, or even worse, a bot attempts access? Without continuously evaluating these contextual signals, “Remember Me” might meet the bar for user experience but falls short on adaptive security — failing to introduce the right friction at the right moment.

This is where PingOne Protect steps in. It continuously analyses behavioural and contextual signals across multiple attack vectors to assign risk scores and trigger appropriate mitigation or action, to ensure convenience is not achieved at the expense of security.

To learn more about the use cases for PingOne Protect integration with PingOne Advanced Identity Cloud (P1AIC) check out this link.

Use Case

In this blog, we’ll enhance the Persistent Cookie feature in PingOne Advanced Identity Cloud — the functionality that enables the “Remember Me” capability by integrating it with PingOne Protect.

Here’s how it works:

During the initial login, PingOne Protect evaluates the context and returns a risk score:

If the score is low, a Persistent Cookie (PCookie) is set, and the login proceeds as normal.
If the score is not low, no PCookie is set — effectively disabling “Remember Me” for that session, but does so silently, without disrupting the user experience.

On subsequent visits, if a valid PCookie is found, PingOne Protect performs another risk assessment:

If the risk remains low, the cookie is trusted, a new session is created automatically and the user is seamlessly signed in.
If the risk is elevated, the user isn’t blocked outright; instead, the PCookie is deleted and they’re redirected to re-enter their credentials — introducing just the right level of friction, at the right moment, based on the current context and signals.

Solution

Let’s get building! 💪

Before we dive in, it’s worth noting that this solution showcases the power of the PingOne platform — apart from a single Custom Node used to display nodeState variables for clarity and education, it’s built entirely with out-of-the-box nodes, requiring no customisation or extensions.

Setup a Mapped PingOne Environment

In this section we’ll create a PingOne environment with PingOne Protect deployed:

If you have a PingOne subscription navigate to this page and hit “Sign On” at the top right of the page and login. On success you’ll be re-directed to the https://console.pingone.eu/ page. If you don’t have a subscription, you can get a demo environment through this link. Enter your business email address and hit “Try Ping”.
From the PingOne Console > Hit Environments on the left panel > Blue + icon next to Environments.
Select Build your own solution > click PingOne Protect > Hit Next.

On the environment name enter an appropriate name, for example env-pingoneaic-**mycompany-ew2-sandbox1** > Select the region > Hit Finish.

Create a Worker Application

Follow these steps to create OIDC credentials for the PingOne AIC tenant to integrate with PingOne Protect. Note the PingOne API and Authorization URLs, for example https://auth.pingone.com, https://auth.pingone.eu etc.

Create Environment Secrets and Variables (ESVs) in P1AIC

Follow these steps to create three ESVs that map to the PingOne Worker Credentials from the last step.
Additionally, create an ESV named esv-hmac-signing-key (string secret) to sign the persistent cookie. Generate a 256-bit key using one of the following commands:
- OpenSSL: openssl rand -base64 32
Finally create an ESV (string variable) called esv-persist-cookie-domainwith a value of the Fully Qualified Domain Name of your tenant. For example openam-darinder-test.forgerock.io.

These ESVs make it easy to update configuration values when promoting to higher environments.

Create a PingOne Service in P1AIC

Follow these steps to create a PingOne Service in your P1AIC tenant. For the secondary configuration be sure to use the ESVs defined above.

After creating the configuration set the PingOne API Server URL and Authorization Server URL as per the address noted in the “Create a Worker Application” section:

Import the Custom Display NodeState Node

Download Display-NodeState.json from GitHub here to your local machine.
From the P1AIC platform admin UI, expand Journeys on the left navigation panel > Custom Nodes
Click Import Nodes (or Import if other Custom Nodes are present) > Browse > open Display-NodeState.json > Import Nodes > Done. A new node called Output Variable from NodeState should be created.

Journey Import

From the journey_exports directory here, download the journey to your local machine.
From the P1AIC platform admin UI, expand Journeys on the left navigation panel > click Journeys > Import.
If need be take a backup or skip.
Click Browse > find the PersistWithProtect-journeyExport.json file > Open > Next > Start Import.

A few points to note:

The PingOne Protect Evaluation nodes uses the default Risk Policy Set ID. As a best practice a new risk policy should be created and the ID set in this parameter. From the PingOne Console > Expand Threat Protection > Risk Policies > Global Policies Blue + > Set a name > Configure as required > Apply > Copy the resulting Policy ID into this parameter. For example a05cccb8-ada5–44e3-a6cd-cefdbc0c942f
Additional BOT_MITIGATION and AITM_MITIGATION (Adversary-In-The-Middle) items were added to the Recommended Actions parameter of the PingOne Protect Evaluation nodes to demonstrate the node’s flexibility in mapping specific risk results to additional outcomes.
The PingOne Protect Result node captures additional context just before the session is created, ensuring maximum accuracy for future assessment of the user’s risk posture and behaviour.

Journey Breakdown

This journey demonstrates how to implement a “Remember Me” (persistent login) flow enhanced with PingOne Protect risk evaluation.
It combines persistent cookie management with adaptive risk analysis to allow seamless logins for low-risk sessions while enforcing re-authentication for higher-risk ones.

On every execution of the journey, the PingOne Protect Initialize node runs first to begin context and device data capture.

The journey then checks for the presence of a persistent cookie named persist-session.
If persist-session is found:
- The PingOne Protect Evaluation node calls PingOne Protect to evaluate the context and calculate risk.
- For a Low risk outcome, the PingOne Protect Result node is invoked, and seamless “Remember Me” functionality is preserved.
- For any other outcome, the persistent cookie is removed, the PingOne Protect Risk value stored in nodeState is displayed for insight, and the user is redirected to authenticate again.
If persist-session is not found:
- The user is prompted for their username and password, and the PingOne Protect Evaluation node again evaluates context and risk.
- If a Low risk outcome is returned, a new persistent cookie is set, enabling “Remember Me” on future logins.
- For all other outcomes (except ClientError, which shows an error message), the PingOne Protect Risk value is displayed for eudcation and understanding.
- Login is still permitted — the session proceeds, but without setting the persistent cookie — ensuring user access is not disrupted, only “Remember Me” functionality is withheld.

Demo

Check out the video below for a live demo

PingOne Protect offers powerful monitoring and visual dashboards that translate complex security data into clear, actionable insights. With real-time visibility into analysed events, risk trends, geolocation anomalies and high-risk user behaviour, organisations can quickly assess and respond to emerging threats. Here’s an example dashboard:

Conclusion

The integration of PingOne Protect with PingOne Advanced Identity Cloud elevates a simple “Remember Me” feature into an intelligent, adaptive security capability. By continuously evaluating contextual and behavioural risk, it ensures that convenience does not come at the expense of protection.

Users enjoy seamless, low-friction logins when their behaviour is trusted, while higher-risk sessions automatically trigger the right level of friction — discreetly and without disruption. The result is a smarter, more secure “Remember Me” experience that balances usability with robust risk-based control — all achieved through a no-code, out-of-the-box Ping Identity platform implementation.

Ping Identity Developer Portal Blog

Hardening the handoff: a pattern for app-to-web single sign-on

The session transfer problem

A standards-based pattern for secure session transfer

Enabling secure session transfer on top of PAR

TL;DR

“Next time on…”

References and further reading

We Rebuilt the PingOne API Docs. Here’s What’s New.

Introduction

It’s a lot faster and easier to navigate

Test endpoints in your browser

Update your bookmarks

Let us know what you think

Next steps

Securing MCP Servers with Ping’s MCP Gateway

Where PingGateway sits as your MCP security gateway

What PingGateway adds for MCP servers

What capabilities does PingGateway provide?

Seeing it in action: the “unauthenticated” request

Benefits for the MCP server developer

Get started!

Next steps

Introducing the PingOne Advanced Identity Cloud (AIC) MCP Server

What Exactly is an MCP Server?

How the AIC MCP Server Works

Why This Matters: MCP Adoption Is Evolving

Core Capabilities: 35+ Tools Across Five Categories

Getting Started: Hands-On Walkthrough

Step 1: Configure Your MCP Client

Step 2: Authenticate

Step 3: Make Your First Tool Call

Real-World Use Case: Debugging Authentication Issues

1. Analyze the Bug and Journey

2. Reproduce with Test Users

3. Trace Logs & Identify the Root Cause

4. Update & Re-test

Security and Caveats

Next Steps: Try It Today, Give us Feedback

References

Introducing the PingOne MCP server

Introduction

What Is MCP?

What is the PingOne MCP Server?

Getting Started: From Zero to First Tool Call

1. Install the Server

2. Set Up a Worker Application in PingOne

3. Configure Your MCP Client

Real-World Use Case: Prepare an Environment for App Development

Security Considerations

Next Steps: Try It Today, Give us Feedback

References

Rapidly Deploying PingGateway with PingOne Advanced Identity Cloud (P1AIC)

Introduction

Scenario

What the Script Deploys

Architecture Overview

Script Execution

Step 1 — Download Assets aond Configure Networking

Step 2 — Configure the Script

Step 3 — Configure P1AIC

Step 4 — Execute the Script

Step 5 — Validate Deployment

Step 6— Stop/Start the

Script Breakdown

1. Environment Validation

2. Clean Installation Handling

3. PingGateway Deployment

4. Script Execution Mode

5. Sample Application Deployment

6. Route Configuration

Conclusion

Further Reading

Securing High-Risk Actions: Transactional Authorization over REST

Introduction

Use Case

Solution

Conclusion

Smarter “Remember Me” with PingOne Protect

Introduction