Credentials
On the Credentials page, you can create a credential such as Basic or OAuth2 for the required integration. This page also provides an overview of all credentials in your MIP, including their names and types.
| Field | Description |
|---|---|
| Name | Credential Name |
| Type | Credential Type. Basic, OAuth2, AWS, Azure, Google Pubsub can be selected. |
The following types of credentials can be defined in MIP:
- Basic: Basic authentication is a straightforward method where a client authenticates to a server using a combination of a username and password.
| Field | Description |
|---|---|
| Basic Username | This is the unique identifier assigned to an individual user. It helps the server identify who is trying to access the protected resource. |
| Basic Password | This is the secret passphrase associated with the username. It serves as a form of authentication to verify that the user is who they claim to be. |
- OAuth2: OAuth 2.0 is a protocol that facilitates users granting access to an application with specific permissions, overseeing the authorization process. The primary objective of OAuth 2.0 is to offer authorized access to designated resources without the need to share a user's credentials.
| Field | Description |
|---|---|
| OAuth2GrantType | This defines the method used by the client application to request an access token. Client Credentials: Used for machine-to-machine authentication where the client is the resource owner. Password Credentials: Allows the client to authenticate using the resource owner's credentials directly. |
| Token URI | This is the endpoint where the client application exchanges the authorization grant for an access token. It's typically provided by the OAuth 2.0 server. |
| Client ID | This is a public identifier for the client application. It is typically a long alphanumeric string. The client ID is not considered confidential, meaning it can be safely shared with the authorization server, resource server, and potentially other parties involved in the OAuth flow. The client ID helps the authorization server identify which client application is making the request. |
| Client Secret | This is a confidential key known only to the client application and the authorization server. It is used to authenticate the client application when making requests to the authorization server, such as exchanging an authorization code for an access token. The client secret adds an extra layer of security by ensuring that only authorized client applications can access protected resources. It should be kept confidential and not exposed to users or other parties. |
| OAuth2 Scope | Scope defines the specific permissions or access rights that the client application is requesting from the resource owner. It limits the scope of the access token granted to the client. For example, a scope might specify access to read a user's profile information, post on their behalf, or access certain resources. The authorization server may require the resource owner's approval for granting access based on the requested scope. |
| Send As | It refers to the method by which OAuth 2.0 clients transmit credentials to the authorization server. |
- Azure: When you create an Azure resource like a storage account Azure automatically generates two access keys, also known as primary and secondary keys. These keys serve as the primary means of authenticating requests to that specific resource. Azure credentials authenticate using this key to access Azure Services.
| Field | Description |
|---|---|
| Azure Access Key | Azure Access Key is an authentication key used to gain access to Azure services, specifically storage accounts. This is important for security and allows only authorized users to perform certain operations. Azure credentials authenticate using this key to access the Azure services. |
- AWS: By using the Access Key and Secret Key together, the user or role is authenticated and authorized to access AWS services. AWS's identity and access management tools, such as IAM roles and policies, must be configured correctly to minimize unnecessary access and authorizations. AWS credentials authenticate using these keys to access Amazon Web Services.
| Field | Description |
|---|---|
| AWS Access Key | An access key is a unique identifier that AWS uses to associate requests with the correct AWS account. When you create an access key, AWS provides you with two components: an access key ID and a secret access key. The access key ID is a public identifier, while the secret access key is a confidential key known only to the AWS account holder and AWS. |
| AWS Secret Key | The secret key is a confidential piece of information that serves as the password for the access key ID. It is used to cryptographically sign requests sent to AWS to prove the identity and authorization of the requester. |
- Google Pubsub: Google Cloud Pub/Sub employs Service Accounts as an authentication mechanism for connecting to the service on the Google Cloud Platform (GCP). The Service Account Key file serves as the means to both authenticate and authorize the Service Account, housing essential components such as private keys and additional authentication details. Google Pubsub credentials authenticate using this key to access the Google Pub/Sub service.
| Field | Description |
|---|---|
| Service Account Key | A service account key is a file that contains the necessary credentials for authenticating your application with GCP services on behalf of the associated service account. When you create a service account key for Google Cloud Pub/Sub, it includes a unique identifier (client ID), a private key, and other metadata. |
Clicking the three dots under the "Action" heading offers the following options:
- Credential Used Where: Lists the flows where the relevant credential is used.
- Edit Credential: Allows changing credential details.
- Delete Credentials: Allows the removal of credentials.