Introduction to OAuth
OAuth is an open standard for authorization.
In Maltego we use OAuth to allow users/analysts to log into third party providers with their credentials and have an access token returned to the tool. This access token can then be sent to the Transform which in turn can request information from the provider on behalf of the user/analyst.
This is beneficial for authorizing specific users’ access to certain Transforms, as illustrated below:
Use Case Example:
Data Partner [XYZ] has 10 Transforms. 5 of which can be run by anybody and 5 of which can only be run by verified regional Law Enforcement Analysts (LEAs). These analysts can be seconded from any of the member countries and can change without much notice. How can [XYZ] handle this authentication challenge?
Solution:
The Regional Law Enforcement Agency [RLEA] has an Authentication Directory (AD) which supports OAuth. [XYZ], through the required processes, creates a developer application that will be allowed access to the relevant [RLEA] AD API endpoints and configures the Transforms to prompt the analysts to login on the resource provider web form, confirming their identity and verifying allowed authorizations before executing the Transform.
OAuth does not share password data, but instead, uses authorization tokens to prove an identity between consumers and service providers. Maltego does not have visibility of the user’s token as it transmitted through the Maltego ecosystem. We use a customer generated public cryptography Key pair to securely encrypt and decrypt the token. Currently, Maltego supports OAuth 2.0 (OAuth 1.0a is still supported for backward compatibility purposes only).
Authentication Grant Flows
Below are the various ways in which a client can acquire an access token, four types are specified in RFC6749:
- Authorization code grant flow: Requires a user to explicitly grant access to resources
- Implicit grant flow: Requires a user to explicitly grant access to resources but is meant for applications which cannot keep a client secret safe
- Client credentials grant flow: Requires credentials in the client and are used only by trusted first-party clients
- Client credentials grant: This grant is suitable for machine-to-machine authentication where a specific user’s permission to access data is not required.
Maltego Supported Authentication Grant Flows
Table 1: Supported authentication flows In Maltego
Authorization Grant Type | OAuth Type | Maltego Inbuilt Support | Knowledge Base URL | Comments |
Authorization code grant | 1, 2 | *YES via TDS – public or Internal TDS | Case by case basis. Fully tested providers: Azure AD, Okta, LinkedIn | |
Implicit grant | 1, 2 | *YES | Case by case basis. | |
Resource owner credentials grant | 1, 2 | NO | Request Code Samples | Use Requests, OAuthlib, other libraries |
Client credentials grant | 1, 2 | NO | Request code Sample | OAuthlib, other libraries |
Note: We support the RFC6749 standard implementation of OAuth, unfortunately some providers might offer custom OAuth implementations, and these will fail to work with Maltego.
Summary Steps to Integrate OAuth in Maltego
- Configure the required OAuth Setup [App Develop Credentials] on the Resource Provider service e.g. LinkedIn
- Configure OAuth Settings in the Maltego Transform Distribution Server
- Develop Transforms that use authorized credentials as tokens received from the Maltego Client. Use the OAuth helper methods in the maltego-trx library.
- Install the Transform Seed in the Maltego Client
- Provision User/Analysts with permissions for required Transforms
- Authorized analysts will be prompted to login on the resource provider website before using the Transforms