Service Authentication — Guide37

IBusinessServiceAuthProvider

public interface IBusinessServiceAuthProvider
{
    Task<Dictionary<string, string>> GetAuthHeadersAsync(
        string serviceId,
        CancellationToken cancellationToken = default);
}

public enum AuthType
{
    None,
    ApiKey,
    BearerToken,
    MutualTLS,
    TokenPassThrough   // passes the calling actor's token
}

Auth Type Behaviors

AuthType	Header Added	Credential Source
`ApiKey`	`X-Api-Key: {key}`	`ICredentialResolver` by service credentialId
`BearerToken`	`Authorization: Bearer {token}`	Service account token from `ICredentialResolver`
`MutualTLS`	TLS client certificate on the `HttpClient`	Certificate from certificate store
`TokenPassThrough`	`Authorization: Bearer {actor-token}`	Current execution actor's access token

Token Pass-Through Pattern

When AuthType = TokenPassThrough, the service receives the same bearer token that the workflow execution actor used to authenticate. This means the service enforces its own RBAC against the actor's permissions — not the workflow's service account. Use this pattern when the service should apply user-specific access control:

public class TokenPassThroughAuthProvider : IBusinessServiceAuthProvider
{
    private readonly IHttpContextAccessor _httpContextAccessor;

    public Task<Dictionary<string, string>> GetAuthHeadersAsync(string serviceId, ...)
    {
        var token = _httpContextAccessor.HttpContext?.Request.Headers["Authorization"].ToString()
            ?? throw new InvalidOperationException("No actor token in context");

        return Task.FromResult(new Dictionary<string, string>
        {
            ["Authorization"] = token
        });
    }
}

Never store tokens in node config. Auth is always injected by IBusinessServiceAuthProvider from secure credential storage. Workflow designers cannot see or modify auth credentials — they only specify which service and operation to call.

← Calling a Service Next: Response Mapping →