Securityv0 — Connector Authentication: Integration Options & Feasibility Plan

Date: 2026-03-10 Last updated: 2026-03-11 Status: Active — implementation in progress Context: Inetum technical deep dive preparation. Nicolas Fernandez (pre-sales/technical) flagged that large organizations may not allow service accounts. This document evaluates all feasible authentication approaches per platform.

Implementation Status

Phase	Scope	Status	Reference
Phase 2	ServiceNow — OAuth 2.0 Client Credentials	In progress — code complete, PR open	sv0-connectors#16 (closes #9)
Phase 1	Azure — Client Certificate auth	Planned	sv0-connectors#10
Phase 3	Pluggable auth strategy interface	Planned	sv0-connectors#11
Phase 3	Azure — Workload Identity Federation	Planned	sv0-connectors#13
Phase 3	ServiceNow — Mutual TLS	Planned	sv0-connectors#12

Operator guide: docs/integrations/servicenow/authentication.md

---

1. Problem Statement

Securityv0 connectors need read-only, metadata-only access to customer environments to discover non-human identities and map execution authority paths. Current implementations use client secrets (Azure) and basic auth (ServiceNow) — methods that rely on long-lived stored secrets.

Enterprise customers with mature security postures may require:

• No long-lived secrets
• Certificate-based authentication
• No human-tied service accounts
• Time-bound, revocable credentials
• Auditability of all connector access

This plan evaluates what each target platform supports and what Securityv0 should implement to meet these requirements.

---

2. Current State

Platform	Auth Method Today	Credential Type	Long-Lived Secret?
Microsoft Entra ID / Graph	OAuth2 Client Credentials (client secret)	AZURE_CLIENT_SECRET	Yes
Azure ARM	Same service principal	Same	Yes
Azure AI Foundry	Same service principal	Same	Yes
ServiceNow	HTTP Basic Auth → OAuth 2.0 Client Credentials (PR #16 open)	SERVICENOW_CLIENT_ID + SERVICENOW_CLIENT_SECRET	Partially (client secret; tokens are short-lived)
GitHub	Not implemented	—	—
AWS	Not implemented	—	—

The connector interface contract (05-connectors.md) defines credential types: 'oauth2_client_credentials' | 'api_key' | 'pat' | 'certificate'. The auth module (sv0_azure/auth.py) currently only instantiates ClientSecretCredential.

Note: The interface contract does not yet model managed_identity, workload_federation, assume_role, or roles_anywhere as first-class auth modes. Adding these requires changes to: the ConnectorConfig.credentials.type union, the connector runtime credential resolution, the platform UI for credential configuration, and the config schema validation. Effort estimates in this plan account for this end-to-end work, not just the SDK credential swap.

---

3. Platform-by-Platform Authentication Options

3.1 Microsoft Entra ID / Graph / ARM / Foundry

All Azure services share the Microsoft Identity Platform. The same Entra App Registration supports multiple credential types simultaneously.

Option A: Client Certificate (X.509)

How it works: An X.509 certificate is uploaded to the Entra App Registration. The connector signs a JWT assertion with the private key and exchanges it for an access token via the OAuth2 client credentials flow with client_assertion instead of client_secret.

Implementation:

• Replace ClientSecretCredential with CertificateCredential from azure-identity SDK
• Accept AZURE_CLIENT_CERTIFICATE_PATH and optional AZURE_CLIENT_CERTIFICATE_PASSWORD env vars
• No changes to API calls, scopes, or permissions — only the credential object changes

Advantages:

• Drop-in replacement in Azure SDK — same get_token() interface
• Microsoft's recommended approach over client secrets for production
• Certificate can be issued by customer's PKI — no secret crosses organizational boundaries
• Private key never leaves the connector's runtime environment
• Supports hardware security modules (HSM) for private key storage

Limitations:

• Certificate must be rotated before expiry (typically 1-2 year validity)
• Customer must upload the public certificate to their App Registration
• Requires customers to have or set up certificate management

Effort: Low — 1-2 days. The Azure SDK handles all JWT signing and token exchange internally.

Enterprise acceptance: High. This is Microsoft's recommended credential type for production workloads. Most enterprise security teams are familiar with certificate-based auth for Entra App Registrations.

Option B: Workload Identity Federation (Federated Identity Credentials)

How it works: The customer's Entra App Registration trusts an external identity provider (IdP) via OIDC federation. The connector authenticates to its own IdP, obtains a token, and exchanges it for an Entra access token — with no secret or certificate stored in Entra at all.

Implementation:

• The connector runtime (e.g., running in our cloud infrastructure or the customer's Kubernetes cluster) obtains an OIDC token from its platform IdP
• Azure SDK's WorkloadIdentityCredential or ClientAssertionCredential handles the token exchange
• Customer configures a federated identity credential on their App Registration, specifying our IdP's issuer URL and subject

Supported federation sources:

• GitHub Actions (OIDC tokens)
• Kubernetes clusters with OIDC issuer (e.g., AKS, EKS with IRSA)
• Google Cloud Workload Identity
• Any OIDC-compliant IdP

Advantages:

• Zero secrets stored in the customer's Entra tenant
• Strongest security posture — trust is based on identity federation, not stored credentials
• Short-lived tokens only (typically 1 hour)
• Aligns with Zero Trust architecture principles

Limitations:

• Requires our connector infrastructure to have a compatible OIDC IdP
• More complex initial setup for the customer
• Not all customer environments will support federation (some may have restrictive conditional access policies)

Effort: Medium — 3-5 days for implementation, plus infrastructure work to establish our OIDC issuer.

Enterprise acceptance: Very high for mature organizations. This is the direction Microsoft, AWS, and Google are all pushing for cross-cloud workload authentication.

Option C: Managed Identity (System-Assigned or User-Assigned)

How it works: If the connector runs inside Azure (e.g., Azure Container Instances, Azure Functions, AKS), the Azure platform automatically provides credentials. No secrets, certificates, or configuration needed.

Implementation:

• Use ManagedIdentityCredential or DefaultAzureCredential (which tries Managed Identity first)
• Customer grants RBAC roles directly to the managed identity

Advantages:

• Zero credential management — fully platform-managed
• Automatic token rotation
• Simplest operational model

Limitations:

• Only works when the connector runs inside Azure
• Not applicable for our SaaS-hosted deployment model unless we deploy per-customer connector instances in their Azure subscriptions

Effort: Low — 1 day. The SDK handles everything.

Enterprise acceptance: Highest. This is Microsoft's top recommendation.

Recommended approach for Azure

Implement a credential chain using Azure SDK's ChainedTokenCredential:

ManagedIdentity → CertificateCredential → WorkloadIdentity → ClientSecretCredential

The connector tries each method in order and uses the first one that succeeds. This lets us support all customer environments with a single codebase. The DefaultAzureCredential class already implements a similar chain — we may be able to use it directly.

Configuration would be:

• If running in Azure with managed identity: automatic, no config needed
• If customer provides a certificate: set AZURE_CLIENT_CERTIFICATE_PATH
• If workload identity federation is configured: set AZURE_FEDERATED_TOKEN_FILE + AZURE_AUTHORITY_HOST
• Fallback: AZURE_CLIENT_SECRET (current behavior, for dev/test or customers who accept it)

---

3.2 ServiceNow

Option A: OAuth 2.0 Client Credentials

How it works: ServiceNow issues an OAuth client_id and client_secret. The connector exchanges these for a short-lived access token. API calls use the bearer token, not raw credentials.

Implementation:

• Register an OAuth API endpoint in ServiceNow (System OAuth > Application Registry)
• Connector calls /oauth_token.do with grant_type=client_credentials
• Use the returned access token for subsequent API calls
• Implement token refresh logic (tokens typically expire in 30 minutes)

Advantages:

• Short-lived tokens — compromise window is limited
• Standard OAuth2 flow — well-understood by enterprise security teams
• Token can be scoped to specific API access
• Audit trail of token issuance in ServiceNow

Limitations:

• Client secret is still long-lived (stored in ServiceNow and in our config)
• Requires ServiceNow Washington DC release (2024) or later for inbound client credentials support. Earlier versions only supported client credentials for outbound calls.
• Customer must verify their ServiceNow version supports this

Effort: Low-Medium — 2-3 days. Standard OAuth2 flow, plus token caching and refresh logic.

Enterprise acceptance: High. OAuth2 Client Credentials is the standard API auth pattern for ServiceNow integrations since Washington DC.

Option B: Mutual TLS (mTLS)

How it works: Both client and server present X.509 certificates during the TLS handshake. ServiceNow validates the client certificate against a configured trust chain and maps it to a ServiceNow user account.

Implementation:

• Customer configures a certificate-to-user mapping in ServiceNow
• Connector presents the client certificate on every HTTPS request
• ServiceNow instance must have mutual authentication enabled
• Uses Python requests library with cert= parameter (client cert + key)

Advantages:

• No passwords or secrets — authentication is purely certificate-based
• Strongest auth option available for ServiceNow
• Certificate can be issued by customer's enterprise PKI
• Meets the strictest "no service accounts with passwords" policies

Limitations:

• ServiceNow mutual auth configuration is non-trivial for customers
• Requires ServiceNow to be configured with a trust anchor (customer's CA)
• Certificate-to-user mapping must be maintained
• Not all ServiceNow instances have mTLS enabled — may require a platform team request

Effort: Medium — 3-4 days. TLS client cert configuration plus testing across ServiceNow versions.

Enterprise acceptance: High for security-conscious organizations. This is the approach used by other enterprise integration platforms (e.g., ServiceNow-to-ServiceNow instance communication uses mutual auth).

Option C: OAuth 2.0 with JWT Bearer (Token-Based)

How it works: Instead of client_secret, the connector signs a JWT with a private key and uses the urn:ietf:params:oauth:grant-type:jwt-bearer grant type. ServiceNow validates the JWT signature against a registered public key.

Advantages:

• No long-lived secret — private key never leaves the connector
• Combines the benefits of OAuth2 (short-lived tokens) with certificate-based auth (no shared secrets)

Limitations:

• Requires ServiceNow to support JWT bearer assertions (available in newer releases)
• More complex setup than basic OAuth2

Effort: Medium — 3-4 days.

Recommended approach for ServiceNow

Primary: OAuth 2.0 Client Credentials — broadest compatibility, standard pattern, low effort. For high-security customers: Mutual TLS or JWT Bearer — offer as an alternative when customers require certificate-based auth.

Implement the connector with a pluggable auth strategy:

AUTH_METHOD = "basic" | "oauth2_client_credentials" | "mtls" | "jwt_bearer"

---

3.3 AWS (New Connector)

Option A: Cross-Account IAM Role (AssumeRole)

How it works: Customer creates an IAM role in their AWS account with a trust policy that allows our connector's identity (either our AWS account ID or an external identity) to assume it. The connector calls sts:AssumeRole and receives temporary credentials (access key + secret key + session token, valid 1-12 hours).

Implementation:

• Connector uses boto3 with sts.assume_role()
• Customer provides: role ARN, external ID (for cross-account security)
• Temporary credentials are used for all subsequent API calls

Advantages:

• No long-lived credentials stored on either side
• Customer controls exactly what the role can access via IAM policy
• External ID prevents confused deputy attacks
• Standard AWS pattern for third-party integrations
• Customer can revoke access instantly by modifying the trust policy

Limitations:

• Requires our connector to have an AWS identity to assume the role from (our own AWS account, or a starting credential)
• Session duration is configurable (1-12 hours), must handle credential refresh

Effort: Medium — 3-5 days for initial AWS connector scaffold plus AssumeRole implementation.

Enterprise acceptance: Very high. This is AWS's recommended approach for third-party access and is the standard pattern used by every major cloud security vendor.

Option B: IAM Roles Anywhere (X.509 Certificate)

How it works: AWS IAM Roles Anywhere allows workloads outside AWS to authenticate using X.509 certificates issued by a trusted Certificate Authority (CA). The certificate is presented to the Roles Anywhere endpoint, which returns temporary STS credentials.

Implementation:

• Customer registers their CA (or AWS Private CA) as a "trust anchor" in IAM Roles Anywhere
• Customer creates a profile mapping the trust anchor to an IAM role
• Connector presents its X.509 certificate to the Roles Anywhere endpoint
• AWS returns temporary credentials scoped to the configured role

Advantages:

• Pure certificate-based auth — no AWS access keys anywhere
• Customer maintains full control via trust anchor and IAM policies
• Designed specifically for external/on-premises workloads
• Temporary credentials (same as AssumeRole)

Limitations:

• Requires the customer to set up IAM Roles Anywhere (relatively new AWS feature, GA since 2022)
• Requires PKI infrastructure for certificate issuance
• More complex initial setup than cross-account roles

Effort: Medium-High — 4-6 days.

Enterprise acceptance: High for security-mature organizations. Aligns with "no long-lived AWS credentials" policies.

Recommended approach for AWS

Primary: Cross-Account IAM Role with External ID — broadest compatibility, standard pattern. For certificate-required environments: IAM Roles Anywhere.

AWS Scope Clarification (for Inetum)

Target AWS connector scope:

1. IAM and identity metadata — IAM users, roles, policies, access keys, service-linked roles
2. Automation services — Lambda functions, Step Functions, EventBridge rules, ECS/EKS workloads
3. AI/ML services (equivalent to Azure Foundry) — Bedrock agents, SageMaker endpoints
4. Cross-service execution paths — which identities trigger which automations, what resources they access

This is a connector development effort beyond auth alone. The auth approach (cross-account role) works identically regardless of which AWS services we query.

Open design questions (noted in 05-connectors.md):

• Multi-account scoping: AWS Organizations vs. per-account role assumption
• IAM condition modeling: IAM policies with conditions (e.g., StringEquals, IpAddress) add complexity beyond simple role-to-resource mapping
• These are scoping and modeling challenges, not auth blockers

---

3.4 GitHub (New Connector)

Option A: GitHub App (Recommended)

How it works: We register a GitHub App. The customer installs it on their organization with specific repository permissions. The connector uses a private key to sign a JWT, exchanges it for a short-lived installation access token (1 hour), and uses that token for API calls.

Advantages:

• Not tied to any human user — represents the application itself
• Fine-grained, repository-level permissions
• Short-lived tokens (1 hour)
• Org admins control installation and permissions
• Audit log entries attribute actions to the app, not a user

Limitations:

• Private key must be securely stored
• Token refresh needed every hour

Effort: Medium — 3-5 days.

Enterprise acceptance: Very high. This is GitHub's recommended approach for automated integrations.

Option B: Fine-Grained Personal Access Token

How it works: A user generates a token scoped to specific repositories and permissions.

Advantages: Simple setup. Fine-grained permissions. Limitations: Tied to a human user. Token is long-lived.

Recommended only as a quick-start option for evaluations, not for production.

---

4. Implementation Priority

Phase 1: Azure Certificate Auth (Immediate — addresses Inetum concern directly)

Task	Effort	Impact
Add CertificateCredential support to sv0_azure/auth.py	1-2 days	SDK credential swap (drop-in)
Extend ConnectorConfig.credentials.type to include certificate with cert path/password fields	1-2 days	Config schema + validation
Implement credential chain (DefaultAzureCredential or custom chain)	1-2 days	Runtime credential resolution logic
Update deployment docs with certificate setup instructions	1 day	Customer-facing documentation
Phase 1 total	4-7 days

Phase 2: ServiceNow OAuth 2.0 (Short-term)

Task	Effort	Impact
Add OAuth 2.0 Client Credentials flow to ServiceNow client	2-3 days	Modern auth for ServiceNow Washington DC+
Token caching and refresh logic	1 day	Operational reliability
Update config schema for ServiceNow auth method selection	1-2 days	Config + UI
Update deployment docs	1 day	Customer-facing documentation
Phase 2 total	5-7 days

Phase 3: Auth Strategy Abstraction (Medium-term)

Task	Effort	Impact
Pluggable auth strategy interface for connectors	2-3 days	Clean architecture for multiple auth methods per platform
Extend ConnectorConfig.credentials.type union for managed_identity, workload_federation	2-3 days	Schema + runtime + UI for new auth modes
Workload Identity Federation support (Azure)	3-5 days	Zero-secret auth for Azure (plus OIDC issuer infra work)
Mutual TLS support for ServiceNow	3-4 days	Certificate auth for ServiceNow
Phase 3 total	10-15 days

Phase 4: New Platform Connectors (Longer-term)

Task	Effort	Impact
AWS connector with cross-account role (includes assume_role + roles_anywhere auth modes, config schema, IAM policy template)	2-3 weeks	New platform coverage
GitHub App connector (includes JWT signing, installation token flow, config schema)	2-3 weeks	New platform coverage

Note on estimates: Phase 1-2 estimates assume the SDK credential work is straightforward (confirmed — Azure SDK and Python requests both support these natively). The additional time accounts for config schema changes, runtime credential resolution, and documentation. Phase 3-4 estimates include infrastructure and design work beyond pure implementation.

---

5. Security Properties Summary

Method	No Long-Lived Secret	Certificate-Based	Zero Trust Aligned	Customer Controls Lifecycle
Azure Client Secret	No	No	No	Partially (can rotate)
Azure Client Certificate	Partially (cert expiry)	Yes	Partially	Yes (customer issues cert)
Azure Workload Identity Federation	Yes	No (OIDC-based)	Yes	Yes (trust policy)
Azure Managed Identity	Yes	N/A (platform-managed)	Yes	Yes (RBAC)
ServiceNow Basic Auth	No	No	No	Partially
ServiceNow OAuth2 Client Creds	Partially (short-lived tokens)	No	Partially	Yes
ServiceNow mTLS	Yes	Yes	Yes	Yes (customer PKI)
AWS Cross-Account Role	Yes (temp creds)	No	Yes	Yes (trust policy + IAM)
AWS Roles Anywhere	Yes (temp creds)	Yes	Yes	Yes (trust anchor + IAM)
GitHub App	Partially (private key stored)	RSA key signs JWT	Partially	Yes (org installation)

---

6. Open Questions for Third-Party Review

1. Credential chain ordering: Should DefaultAzureCredential (which tries ~8 methods) be used, or should we define a narrower custom chain to avoid unexpected auth method selection?

2. Certificate lifecycle management: Should Securityv0 provide tooling to help customers rotate certificates, or is that fully the customer's responsibility?

3. Workload Identity Federation infrastructure: What OIDC issuer should we run? Options include leveraging our cloud provider's identity (e.g., if we run on AWS, we could use IRSA tokens; if on Azure, managed identity federation).

4. ServiceNow version matrix: What's the minimum ServiceNow version we should support? OAuth 2.0 Client Credentials for inbound was added in Washington DC (2024). Should we require it or maintain Basic Auth as a fallback?

5. Multi-method configuration UX: How should the platform UI present auth method selection to customers? Should it auto-detect what's available or require explicit selection?