You can integrate Azure Blob Storage with ODC without SAS, but you’ll need to move away from the “SAS URL per operation” pattern used by the Forge connector and implement one of the supported Azure auth flows yourself.

Based on what you described, here are the options and what is realistic in ODC:

1. Alternatives to SAS in general

Azure Blob Storage supports three main approaches relevant here Security and Access Management > Blob Storage API Security:

1. Shared Access Signature (SAS) – what the Forge connector uses.
2. Account key / Connection string (shared key authentication).
3. Azure AD (OAuth2) / Managed identity – token-based auth using an AAD app registration or managed identity.

The articles explicitly mention SAS and Azure AD as the preferred options for secure access, and refer to shared keys/connection strings as an underlying mechanism but not the recommended way to expose credentials to apps Security Considerations for Azure Blob Storage API.

2. Is there an existing ODC connector without SAS?

From the documentation and typical patterns:

• The reference and demo integrations use SAS for simplicity and POCs, and mention AD-based flows as the more enterprise-ready option Blob Storage Integration with OutSystems.
• There is no mention of an ODC-specific connector that natively uses connection string/access key instead of SAS.

So:
No, there is no standard ODC implementation that uses connection string/access key directly instead of SAS; at least not in the official examples and guidance.

3. Can you build an ODC connector using connection string / access key?

Conceptually, yes, because Blob Storage’s REST API supports Shared Key authentication (HMAC with account key) and the connection string is just a way to store the account name + key. However, in practice:

• You’d need to implement the Authorization header signing in OutSystems (build the canonicalized string, sign with HMAC-SHA256, base64, etc.), for each request type (PUT/GET/DELETE) Blob Storage Technical Overview.
• In ODC you have no server-side .NET extensions, so the signing must be done in pure OutSystems logic or via a separate service you host.

This is technically possible but:

• Complex and error-prone.
• Less secure, because you’re embedding a long-lived account key in your app environment instead of short-lived tokens.

Microsoft’s own guidance is to avoid exposing account keys directly to client apps and favor SAS or AAD-auth flows.

So while you can do it, it’s generally not the recommended approach.

4. Recommended approach for ODC (without relying on user-provided SAS)

Given ODC constraints and Azure best practices, this is the usual pattern:

Option A – Use Azure AD to get an access token and call Blob Storage

1. Register an Azure AD application with permissions to your storage account (i.e., use “Azure AD integration” as described in the articles).
2. Expose the client id/secret and tenant id as ODC environment secrets (site properties / configuration).
3. In your connector:
   • Implement a REST call to Azure AD token endpoint to obtain an access token.
   • Use the Bearer token in the Authorization header for Blob Storage REST calls.
4. Keep the token lifetime short and cache it per request or in memory where possible.

The article describes Azure AD as one of the main mechanisms for securing the Blob API, alongside SAS Blob Storage API Security.

This avoids SAS proliferation but still uses short-lived tokens; you just generate them internally via OAuth2 instead of copying SAS URLs around.

Option B – Use a backend service to generate SAS dynamically (clean “no SAS in UI” approach)

If you want to stick with SAS but not expose them to front-end logic:

1. Create a small backend API (Azure Function / Web App) that:
   • Holds the connection string / account key.
   • Receives requests from your ODC app asking for “upload/download/delete rights to container X / blob Y”.
   • Returns a short-lived SAS for that specific operation.
2. In ODC:
   • Your reusable connector calls this backend first to obtain the SAS.
   • Then uses the SAS with the existing Blob Storage REST API calls.

This pattern is effectively what Microsoft recommends: keep secrets in a trusted backend, surface scoped, time-limited SAS to the app Architectural Considerations > When to Integrate Azure Services with OutSystems.

5. Direct connection string / access key in ODC – should you do it?

To answer your specific sub-questions:

• “Is there any implementation without SAS?”
  Not in the official connectors/examples; they’re built around SAS (and conceptually, AAD for production scenarios).

• “Is it possible via connection string or access key?”
  Theoretically yes, by implementing the Shared Key signature logic in OutSystems. But:

  • It’s non-trivial to get right.
  • It’s less secure if you expose the account key directly to the runtime.
  • It goes against the guidance that favors SAS/AAD and token-based auth Security Considerations for Azure Blob Storage API.

• “If not directly supported, what is the recommended approach?”
  For ODC, the recommended patterns are:

  1. Azure AD-based auth to Blob Storage (no SAS, token-based).
  2. Backend service that uses connection string/account key and issues SAS for your ODC app (SAS used, but managed and short-lived).

Suggested practical direction for your reusable connector

If your goal is a reusable ODC connector that doesn’t depend on manually-provided SAS strings:

1. Implement an auth layer in the connector that:

   • Either calls Azure AD to get a Bearer token, or
   • Calls your backend to get a per-operation SAS.

2. Keep:

   • Storage account name / container name as connector configuration.
   • Client ID/secret or backend URL as environment configuration.

3. Expose simple server actions like:

   • UploadFile(File, Container, BlobPath)
   • DownloadFile(Container, BlobPath)
   • DeleteFile(Container, BlobPath)

internally handling token acquisition and calling the Azure Blob REST endpoints Technical Setup and API Integration for Blob Storage.

If you share more about where you want this connector to be called from (server actions only vs exposing URLs client-side), I can outline a more concrete flow (e.g., whether you should issue “user delegation SAS” for direct browser uploads vs keep everything server-to-server).