Authentication methods

Machine-to-machine (M2M)

For Machine to Machine communication, typical authentication schemes like username + password, social logins, etc. don't make sense. In contrast to general auth flows where an authorization process attempts to establish trust by authorizing a user, in this case what must be authorized and trusted is the client. To be clear, in this case, the client is simply an application, process or even an autonomous system. (e.g. service to service, daemon to backend, CLI client to internal service, IoT tools). Twikit’s M2M flow follows the OAuth2 standard and adopts the client_credentials flow, defined in the OAuth 2.0 RFC 6749 authorization protocol.

Grant type: client credentials

The client credentials grant type is suitable for machine-to-machine authentication in highly trusted scenarios, limited to usage within confidential clients.

Meaning the following security best practices are requested while using the client credentials grant:

• It is mandatory to store client credentials securely and not hardcode them within your application. Use appropriate credential management practices, such as environment variables or secret management services.

• As an extra security measures one of the following ways of authentication can be added:

  • IP Whitelisting: If the IP address of the client application can be shared with Twikit. The IP address will be whitelisted to allow communication with the Twikit API and some specific endpoints.

  • Mutual TLS (mTLS) authentication: Twikit can provide certificates, so the client and server can prove their identities to each other, before communication.

Requesting access

The authorization grant that consists of a client_id, client_secret pair will for now be provided by the Twikit technical team with a secured link that is available for a limited amount of time. Send a request to your Twikit contact, to obtain a valid authorization grant. Since the client authentication (the client_id, client_secret pair) is used as the authorization grant, no additional authorization request is needed.

Obtaining a token

The client credentials grant is very simple to use. An access token can be obtained by sending POST request to the token endpoint of the Twikit Authentication Server (Twikit Idp) with the grant_type=client_credentials.

A successful authorization request results in a response

with following keys:

• access_token – A valid access token.

• expires_in – The length of time (in seconds) that the provided access token is valid.

• token_type – Set to Bearer.

Authentication Flow

1. The client makes a request to the authorization server sending the client ID, the client secret.

2. The authorization server validates the request, and, if successful, sends a response with an access token. Note that, for this grant type, an ID token and a refresh token aren’t returned.

3. The client can now use the access token to request the protected resource from the resource server.

Resources and services

Scope

Within the Twikit API setup, predefined scopes, defined for the available resources (e.g. configurations/configurations.read) are used to allow the client application to manage or retrieve data from the resource server. The client’s level of access and necessary scopes are discussed upon the initial request for an authorization grant and must be approved/granted by the Twikit technical team for the specific client application.

Within the auth flow on the token request, the access token, that is returned, will contain information about the client's level of access. Defining scope on the token call is optional. If the client doesn't define any scopes, the authentication server assigns all scopes that were authorized in the client application configuration upon setup.