Oauth 2.0 support in Studio Thoughts

[jeremydunca]

I recently had a customer reach out to me asking if Oauth was supported in Studio when linking to source control. The answer was/is no. That sent me on a journey to understand why, and what other options there were. I've attached a white paper I put together to explain it from my perspective. Hope this helps. There are a couple of links to understanding IDE and Oauth support within there to help with the discussions you may have with customers. 

Navigating the Need for OAuth Support in ServiceNow Studio

Intro to Studio

ServiceNow Studio is a platform feature that enables developers of all skill-levels to be able to build and maintain applications on the ServiceNow platform. There has been an evolution of build capabilities: From building tables and columns, menu modules, and CMS pages in UI15/16/Next to building full-featured apps in IDE, ServiceNow has invested in helping builders get more done on the platform. App Engine Studio was the first step in showing citizen developers the power of being able to build apps in a low/no-code way. The features from App Engine Studio were deprecated in 2025 and moved into Studio for customers who were licensed to use it to consume. While App Engine Studio still exists, our customers are being encouraged to move to Studio as ongoing product enhancements will cease to exist for App Engine Studio (AES).

Customer Challenge/Scenario:

Customer X wants to be able to utilize the ability to link app builds to source control using a more secure method of authentication, OAuth 2.0 within Studio. Currently, Studio supports basic authentication via HTTPS and SSH. The desire is driven by the fact that they have enabled citizen developers (who traditionally are not enabled on IDE interfaces for development work). Think, Studio and App Engine Studio (deprecated in 2025) are great for your low-coder and citizen developers and IDE is for your pro-coders.

Reason for this request:

Many enterprises now have policies that:

• Ban username/password credentials in tools
• Disallow stored personal access tokens
• Require:
  • Short-lived tokens
  • Centralized identity providers (Okta, Azure AD, etc.)
  • Revocable app registrations

OAuth provides:

• Token expiration
• Scope control
• Revocation without password rotation
• Identity traceability

Basic Auth in Studio (the only currently supported method):

• Static credential sitting in ServiceNow
• Often tied to a service account
• Violates modern IAM policy

ServiceNow Answer/Workaround

ServiceNow suggests using ServiceNow IDE to pull and push code changes to a repo using OAuth. Documentation here and training here. This is more than just a workaround though. This is being proposed as the new way that developers should be operating on the ServiceNow platform. The ServiceNow IDE enables the use of our SDK and Fluent and even the power of AI in Build Agent to not only build new apps but even modify existing scoped apps.

A burning question I hear often is “can I modify existing scoped apps in the IDE that were built in Studio?” and the answer is YES. If you look at the ServiceNow University training link in this paragraph above, you’ll find modules that walk you through the key tenants of using IDE for building new and modifying existing applications.  

The Reality

Back to the challenge of “I want Oauth 2.0 for linking to Source Control in Studio”: Customers are expecting pipeline-grade security from a tool designed for citizen dev convenience. Using ServiceNow Studio as a traditional development environment is not as fully robust in security mechanisms for transporting code as a traditional IDE like Visual Basic, or ServiceNow IDE. We should encourage our customers to be moving from the traditional “move your update sets between environments” mode of thinking into a CI/CD world of managing pipelines in a code repo like GIT.

The Path Forward

The gap here isn't really a product deficiency—it's a positioning problem. We're seeing customers try to force Studio into a role it was never architected to fill. Studio's source control integration was built to give citizen developers a more simplistic on-ramp to version control concepts, not to serve as an enterprise-grade CI/CD pipeline component.

When customers push back on using ServiceNow IDE, it's usually because they're afraid of losing their low-code developers in a more complex environment. But that mindset misses what's actually happening in the market. Citizen developers who are ready to interact with GIT repos directly? They're ready to graduate to IDE. And the ones who aren't? They shouldn't be managing source control credentials at all—that's where your pro-dev or platform teams should be stepping in.

The real conversation we need to be having with customers isn't "how do we get OAuth into Studio"—it's "why are you letting citizen developers push directly to your repos without a proper review process?" Because that's the actual security gap. OAuth support won't fix that.

Recommendations

For ServiceNow Product:

• Document the intentional boundaries between Studio and IDE more clearly in architecture guidance
• Position Studio source control as "training wheels" for version control concepts, not production delivery
• Consider whether Studio's source control integration should exist at all, or if it creates more risk than value

For Customer Conversations:

• Reframe the developer journey: Studio → source control awareness → IDE adoption. Not Studio as the permanent home for everyone.
• Implement proper governance: If citizen devs are building apps that need to be in source control, those apps need peer review. That means pull requests. That means IDE or at least an approval layer that Studio doesn't provide.
• Separate concerns: Let citizen developers build in Studio. Let your platform team or pro-devs handle the source control integration through IDE. This actually improves security and enables your less technical team members.
• Use the right tool for the job:
• Configuration changes that don't require source control? Studio is fine.
• Apps that need version control and deployment pipelines? IDE from the start.
• Citizen dev contributions to existing apps? Build in Studio, but let platform team commit through IDE.

In Summary

The hard truth is that customers asking for OAuth in Studio are solving the wrong problem. They're trying to make a low-code tool behave like an enterprise development environment because they don't want to admit their governance model has holes in it. We do them a disservice by entertaining that request instead of helping them build the right architecture.

If your security team won't allow basic auth credentials in Studio, that's not a bug—that's a feature telling you those users shouldn't be committing to your repos without oversight. Listen to that signal.

Thanks Starlord @Dale Stubblefie  and @Chris Clancy for digging in on this topic with me and helping me consider things I hadn't before.