While evaluating identity management solutions for our containerized microservices, we observed that PingOne's monthly active user (MAU) metric was a significant cost driver. The billing model, common in SaaS identity platforms, can lead to inflated counts from non-human actors like CI/CD pipelines, monitoring bots, or service accounts. This post details a systematic approach to audit and reduce non-essential authentications.
First, implement a usage audit. Export authentication logs and filter for `client_id` values used by automated systems. Key candidates for review:
* Integration tests that run full OAuth flows
* Deployment scripts fetching tokens for configuration
* Health checks or monitoring probes using protected endpoints
* Service accounts for internal tooling
For Jenkins pipelines, avoid having each job run authenticate as a unique user. Instead, use a dedicated technical user with a long-lived token (stored securely in Jenkins credentials) for all CI-related tasks. Cache this token within the pipeline to prevent repeated logins.
```groovy
pipeline {
agent any
environment {
PINGONE_TOKEN = credentials('pingone-ci-service-account')
}
stages {
stage('Integration Test') {
steps {
script {
// Use the pre-authenticated token; do not run 'oauth2-login' here
sh '''
curl -H "Authorization: Bearer $PINGONE_TOKEN"
https://api.pingone.com/v1/environments/${ENV_ID}/applications
'''
}
}
}
}
}
```
In GitHub Actions, leverage `actions/cache` to persist a session token across workflow runs, reducing authentication events. Crucially, configure your applications and APIs to accept machine-to-machine tokens for backend services, bypassing the user-centric PingOne login for internal communications.
Finally, work with your developers to distinguish user-facing applications from backend services. Each should have a separate `client_id` in PingOne, allowing you to monitor and attribute costs accurately. By segregating and optimizing these flows, we reduced our reported MAU by approximately 30%, translating to direct cost savings without impacting end-user experience.
--crusader
Commit early, deploy often, but always rollback-ready.
Auditing client_ids is a good start, but you're just treating symptoms. The real problem is tying your billing to opaque, vendor-defined metrics like "MAU" in the first place.
Push back on that model. Negotiate a flat rate for service accounts or a fixed-price tier based on your actual employee count, not every random system token. Otherwise you'll just be playing whack-a-mole with bots forever.
That Jenkins example is still creating a monthly active user, by the way. Just one instead of many. It's still a cost.
SQL is enough
You're right that pushing for a better billing model is the ideal outcome. But in my experience, renegotiating these core metrics is often a non-starter with large vendors until you have concrete data.
The audit isn't just whack-a-mole; it's the ammunition you need for that negotiation. Coming to the table with proof that 30% of your MAUs are Jenkins pipelines gives you a much stronger case for that service account tier you mentioned.
Otherwise, you're just asking for a discount based on a hunch.
Keep it real
Your point about caching the token within the pipeline is critical, but I'd extend the audit to look at token refresh behavior specifically. That long-lived token is still likely hitting the authorization server for a refresh, and those refreshes often count as an authentication event. You need to check your log exports for `grant_type=refresh_token` on those technical client IDs.
Consider implementing a simple daemon-side token cache for your CI system, so a single refresh serves all concurrent jobs, rather than each job initiating its own refresh cycle. This requires a bit more infra but can further squash those redundant auth events the vendor counts.
Logs don't lie.
It's not an either/or choice. You do the audit *to* get the data *for* the negotiation.
You can't push back effectively with "this model is opaque." You push back with "30% of our MAUs are from these five service clients, here's the log proof. We need a different price structure for them."
Otherwise they'll just tell you to follow your own guide and clean up your integration.
Trust but verify.