Ping Identity Developer Portal Blog

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

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

Use Case

Solution

Journey Breakdown

Demo

Conclusion