niveathika commented 7 months ago

Description: The old ballerina twilio connector upto 3.2.0 supported both authToken and APIKey authentication. https://github.com/ballerina-platform/module-ballerinax-twilio/blob/48c94650281eff75712b5237a265c8f73b83b927/twilio/types.bal#L25

But in the latest connector released early this year (4.x.x) only supports the authToken auth.

Problem

AuthToken grants access to the entire Twilio account. Sharing it carries a higher security risk. It maybe useful for local testing but not ideal for production.

API Keys offer more granular control, can be created for specific applications or functionalities, can be revoked if compromised without affecting your entire account.

Suggested Solution

Can we add support for API Key auth as well?

ayeshLK commented 2 weeks ago

Even though this is not ideal, following code can be used as a workaround IMO

import ballerinax/twilio;

configurable string sid = ?;
configurable string apiKey = ?;
configurable string apiSecret = ?;

public function main() returns error? {

    twilio:Client twilioEp = check new (config = {
        auth: {
            username: apiKey,
            password: apiSecret
        }
    });

    twilio:Message msg = check twilioEp->createMessage(
        {
            To: "<to-address>",
            Body: "This is a sample message"
        }, 
        accountSid = sid
    );
}

SachinAkash01 commented 2 weeks ago

Even though this is not ideal, following code can be used as a workaround IMO

import ballerinax/twilio;

configurable string sid = ?;
configurable string apiKey = ?;
configurable string apiSecret = ?;

public function main() returns error? {

    twilio:Client twilioEp = check new (config = {
        auth: {
            username: apiKey,
            password: apiSecret
        }
    });

    twilio:Message msg = check twilioEp->createMessage(
        {
            To: "<to-address>",
            Body: "This is a sample message"
        }, 
        accountSid = sid
    );
}

This approach works well for the API Key authentication. However, since it's not the most usable way, we are working on a proposal to update our API.

SachinAkash01 commented 1 week ago

Proposal: Add API Key Based Authentication for Ballerina Twilio Connector

Summary

Implement the capabilities to support API Key based authentication for the Ballerina Twilio Connector.

Goals

Enhance the Ballerina Twilio Connector by adding support for API Key based authentication for client validation.

Motivation

In the current Ballerina Twilio connector (version 4.x.x), only Auth Token-based authentication is supported, which grants full access to the associated Twilio account. While this is sufficient for local testing or low-risk scenarios, it poses significant security challenges in production environments. Auth Tokens allow any client with access to interact with the entire Twilio account, including sensitive resources and data, exposing a risk of unauthorized access if credentials are compromised.

API Key-based authentication provides a robust alternative by enabling finer-grained control over access permissions. Twilio’s API Key authentication allows developers to issue and manage multiple keys with tailored scopes, specific to certain applications or functionalities. API Keys can be rotated, revoked, or regenerated without impacting the overall account integrity, thereby reducing downtime in the event of a compromise and allowing for quicker incident response.

By implementing API Key-based authentication in the Ballerina Twilio connector, we can offer developers a more flexible and secure mechanism for managing Twilio API interactions. This approach aligns with industry best practices, improving security posture and minimizing the risks associated with broad-scope credentials in production environments.

Description

In the current approach (Auth Token based authentication) of the Ballerina Twilio connector requires an accountSidand authToken, which grants full access to the Twilio account. To improve security and offer more granular control over access, this proposal introduces support for API Key-based authentication. API Key-based authentication allows developers to use an apiKey, apiSecret, and accountSid limiting access to specific resources and allowing for easier key management

Enhanced ConnectionConfig Structure:

The ConnectionConfig type will be modified to support both authentication mechanisms. The auth field will be accepting either AuthTokenConfig or ApiKeyConfig allowing the user to specify their preferred authentication method.

@display {label: "Connection Config"}
public type ConnectionConfig record {|
    AuthTokenConfig|ApiKeyConfig auth;
    //other fields
|};

Two distinct records AuthTokenConfig and ApiKeyConfig, define the required fields for each authentication type.

public type AuthTokenConfig record {|
    string accountSid;
    string authToken;
|};

public type ApiKeyConfig record {|
    string accountSid;
    string apiKey;
    string apiSecret;
|};

This approach improves security and flexibility, allowing granular control over Twilio account access without exposing the full account credentials in production settings.

NipunaRanasinghe commented 1 week ago

@SachinAkash01 LGTM! small suggestion regarding the naming convention used for auth config record types; shall we consider adding the suffix Config instead of Credentials for the proposed record names (AuthTokenCredentials and ApiKeyCredentials)? We've consistently used the suffix Config to define auth options in other library modules (e.g., HTTP).