Sitecore Marketplace App Development: Authentication, Permissions, and Security

Introduction

Developing applications for the Sitecore Marketplace means developing not only features but also the source code that is going to be executed in the context of enterprise content platforms. Authentication and security are no add-ons here they're the foundation.

This document provides the information that developers should have when developing Marketplace applications that are robust enough and comply with Sitecore platform security principles.

1. Understanding the Sitecore Marketplace App Model

Applications on the Sitecore Marketplace run on Sitecore's composable DXPs; examples include Sitecore XM Cloud, Content Hub, and Sitecore CDP. Unlike the conventional Sitecore modules, the Marketplace applications are third-party applications running external to the Sitecore system using APIs and OAuth-based authentication flows.

This architecture shift matters for security:

• Apps don't get direct database access
• All interactions go through Sitecore's API layer
• User identity is federated, not locally managed
• Permissions are based on the platform and not the application

The important thing to note here is that being familiar with this concept will prevent you from making the typical developer mistake of thinking that you can port older security concepts to the composable approach.

2. OAuth 2.0 and the Sitecore Identity Server

For the Marketplace applications, Sitecore makes use of an internal Identity Server (IdentityServer4) for authenticating users. In this case, there will be two OAuth 2.0 flow options for applications - either the Authorization Code Flow or the Client Credential Flow depending on the use case.

Authorization Code Flow (user-facing apps):

Code Example:

// Redirect user to Sitecore Identity authorization endpoint

GET /connect/authorize

?client_id=your_client_id

&response_type=code

&redirect_uri=https://yourapp.com/callback

&scope=openid profile sitecore.profile

&code_challenge=<PKCE_challenge>

&code_challenge_method=S256

After the user authenticates and consents, exchange the authorization code for tokens:

Code Example:

POST /connect/token

client_id=your_client_id

&grant_type=authorization_code

&code=<auth_code>

&redirect_uri=https://yourapp.com/callback

&code_verifier=<PKCE_verifier>

Client Credentials Flow (server-to-server):

Code Example:

POST /connect/token

client_id=your_client_id

&client_secret=your_secret

&grant_type=client_credentials

&scope=sitecore.profile.api

Key points:

• Always use HTTPS tokens in transit are non-negotiable
• Store client_secret in environment variables or a secrets manager, never in source code
• Refresh tokens should be rotated on each use
• Set short expiry windows on access tokens (15-60 minutes is standard)

3. Scopes and API Permissions

The API layer of Sitecore utilizes scopes in order to define permissions that the token will have. At the registration stage of your Marketplace app, you specify the required scopes. The user or administrator then grants permission to the required scopes.

Common scopes in the Sitecore ecosystem:

Best practices for scope management:

• Request minimum necessary scopes: don't ask for write access if your app only reads
• Display a clear, plain-language consent screen explaining what each scope does
• Allow users to revoke app access from their account settings
• Log all scope requests and denials for your own audit trail

4. Role-Based Access Control Inside Your App

OAuth handles who the user is. Your app needs to handle permissions after logging in.

If Sitecore authenticates the user and provides token-based access, you still need to apply your RBAC model on any feature that requires more than just read permissions.

A practical pattern:

Code Example:

// Check Sitecore role claims in the JWT

var roles = claimsPrincipal.FindAll("role").Select(c => c.Value);

if (!roles.Contains("sitecore\\Developer") &&

!roles.Contains("sitecore\\Admin"))

{

return Forbid(); // Return 403, not 401

}

Role claim structure in Sitecore JWTs typically follows the domain\\rolename convention. Build your permission checks around these claims rather than maintaining a separate user database this keeps your app in sync with whatever the Sitecore instance defines.

Additionally:

• Separate read and write permission checks at the controller/handler level
• Never expose admin-level endpoints to regular authenticated users
• Use middleware to enforce role checks globally rather than scattering them through business logic

5. Securing API Communication and Data Handling

Authentication gets users in. The following keeps the rest of your app secure.

Token validation:

Every API call your app receives should validate the bearer token before processing. Use a JWT validation middleware:

Code Example:

services.AddAuthentication(JwtBearerDefaults.AuthenticationScheme)

.AddJwtBearer(options =>

{

options.Authority = "https://your-sitecore-identity-server";

options.Audience = "your_client_id";

options.RequireHttpsMetadata = true;

});

Additional security measures:

• Validate iss (issuer) and aud (audience) claims on every token
• Implement token blacklisting or revocation checks for logout scenarios
• Use HttpOnly and Secure flags on any cookies storing session data
• Apply rate limiting on all endpoints authenticated or not
• Never log full tokens; log token metadata (subject, expiry, client ID) instead
• Sanitize all inputs before passing them to Sitecore APIs, even trusted users can send malformed data

Best Practices

• Register your application with only the bare minimum number of scopes: add scopes only when there is an appropriate reason
• Rotate client secrets regularly: consider client secrets to be like passwords rather than long-term credentials
• Always use PKCE in browser-based authentication: avoid using implicit flows in 2024 and beyond
• Make sure your application supports logging out: invalidate tokens from both the server and client sides, then redirect to Sitecore Identity logout URL
• Test with non-administrative accounts: most security holes appear when you are only testing with a user that is an administrator

Conclusion

Developing an app for the Sitecore Marketplace implies developing it for enterprise systems, where security auditing, compliance checks, and multi-tenant platforms are a regular thing. Ensuring proper authentication and authorization from the very beginning will help you avoid nasty rework in the future not to mention the fact that companies will trust your app to secure their entire content management system.

These practices described above – such as using OAuth 2.0 + PKCE, configuring API permissions using scopes, applying role claims for authorization, and performing thorough token validation will serve as your solid base in development.

Written by

Meet Shah

Sitecore Expert

I’m Meet Shah, a Sitecore Certified Software Developer at Arroact Technologies. I work with Sitecore XP, Sitecore Order Cloud, and .NET to build digital experiences that connect content, commerce, and data in a way that actually makes sense for users and teams. 

I’m especially interested in how Sitecore AI can be used to create smarter, more personalized experiences. I like exploring how small improvements in logic or structure can make a big difference in how a system performs and feels. 

Most of my work revolves around taking complex ideas and turning them into solutions that are clear, reliable, and easy to work with. I enjoy building things that don’t just work but continue to work well as they grow.