InfoGrab Docs

HTTP Request 자격 증명

요약

이 자격 증명을 사용하여 다음 노드를 인증할 수 있습니다: 쿼리하려는 앱 또는 서비스에서 요구하는 인증 방법을 사용해야 합니다. SSL 인증서로 인증을 보호해야 하는 경우 필요한 정보는 SSL 인증서 제공을 참조하세요.

이 자격 증명을 사용하여 다음 노드를 인증할 수 있습니다:

사전 요구 사항#

쿼리하려는 앱 또는 서비스에서 요구하는 인증 방법을 사용해야 합니다.

SSL 인증서로 인증을 보호해야 하는 경우 필요한 정보는 SSL 인증서 제공을 참조하세요.

지원되는 인증 방법#

  • 미리 정의된 자격 증명 유형
  • Basic auth (일반 자격 증명 유형)
  • Custom auth (일반 자격 증명 유형)
  • Digest auth (일반 자격 증명 유형)
  • Header auth (일반 자격 증명 유형)
  • Bearer auth (일반 자격 증명 유형)
  • OAuth1 (일반 자격 증명 유형)
  • OAuth2 (일반 자격 증명 유형)
  • Query auth (일반 자격 증명 유형)

일반 자격 증명 유형에 대한 자세한 내용은 HTTP 인증을 참조하세요.

미리 정의된 자격 증명 유형

n8n은 연결하려는 서비스에 사용 가능한 자격 증명 유형이 있을 때마다 미리 정의된 자격 증명 유형을 사용하도록 권장합니다. 일반 자격 증명을 구성하는 것보다 자격 증명을 설정하고 관리하는 더 쉬운 방법을 제공합니다.

미리 정의된 자격 증명 유형을 사용하여 n8n이 플랫폼용 노드를 보유한 일부 API로 커스텀 작업을 수행할 수 있습니다. 예를 들어 n8n에는 Asana 노드가 있으며 HTTP Request 노드에서 Asana 자격 증명 사용을 지원합니다. 자세한 내용은 커스텀 작업을 참조하세요.

미리 정의된 자격 증명 유형 사용#

사전 정의된 자격증명 유형을 사용하려면:

  1. HTTP Request 노드를 열거나 워크플로우에 새로 추가합니다.
  2. **인증(Authentication)**에서 **사전 정의된 자격증명 유형(Predefined Credential Type)**을 선택합니다.
  3. **자격증명 유형(Credential Type)**에서 사용할 API를 선택합니다.
  4. 자격증명(Credential for ) 에서 다음을 선택할 수 있습니다:
    1. 해당 플랫폼의 기존 자격증명이 있으면 선택합니다.
    2. 새 자격증명을 만들려면 **새로 만들기(Create New)**를 선택합니다.

자세한 내용은 커스텀 API 작업을 참조하세요.

기본 인증(Basic Auth) 사용#

앱 또는 서비스가 기본 인증을 지원하는 경우 이 일반 인증을 사용합니다.

이 자격 증명을 구성하려면 다음을 입력합니다:

  • HTTP Request가 대상으로 하는 앱 또는 서비스에 접근하는 데 사용하는 사용자 이름(Username)
  • 해당 사용자 이름에 해당하는 비밀번호(Password)

다이제스트 인증(Digest Auth) 사용#

앱 또는 서비스가 다이제스트 인증을 지원하는 경우 이 일반 인증을 사용합니다.

이 자격 증명을 구성하려면 다음을 입력합니다:

  • HTTP Request가 대상으로 하는 앱 또는 서비스에 접근하는 데 사용하는 사용자 이름(Username)
  • 해당 사용자 이름에 해당하는 비밀번호(Password)

헤더 인증 사용하기#

앱 또는 서비스가 헤더 인증을 지원하는 경우 이 일반 인증 방식을 사용하세요.

이 자격증명을 구성하려면 다음을 입력하세요:

  • HTTP 요청이 대상으로 하는 앱 또는 서비스에 전달해야 할 헤더 Name
  • 헤더의 Value

HTTP 헤더에 대해 자세히 알아보세요.

Bearer 인증(Bearer Auth) 사용#

앱 또는 서비스가 Bearer 인증을 지원하는 경우 이 일반 인증을 사용합니다. 이 인증 유형은 실제로 NameAuthorization으로 설정되고 ValueBearer <token>으로 설정된 헤더 인증입니다.

이 자격 증명을 구성하려면 다음을 입력합니다:

  • HTTP 요청이 대상으로 하는 앱 또는 서비스에 전달해야 하는 Bearer 토큰(Bearer Token)

Bearer 인증에 대해 자세히 알아보세요.

OAuth1 사용#

앱 또는 서비스가 OAuth1 인증을 지원하는 경우 이 일반 인증을 사용합니다.

이 자격 증명을 구성하려면 다음을 입력합니다:

  • Authorization URL: Resource Owner Authorization URI라고도 합니다. 이 URL은 일반적으로 /oauth1/authorize로 끝납니다. 임시 자격 증명이 여기로 전송되어 사용자에게 인증 완료를 요청합니다.
  • Access Token URL: 임시 자격 증명에 대한 초기 요청에 사용되는 URI입니다. 이 URL은 일반적으로 /oauth1/request 또는 /oauth1/token으로 끝납니다.
  • Consumer Key: 클라이언트 키라고도 하며 사용자 이름과 같습니다. 호출에 사용할 oauth_consumer_key를 지정합니다.
  • Consumer Secret: 클라이언트 시크릿이라고도 하며 비밀번호와 같습니다.
  • Request Token URL: 인증 후 임시 자격 증명을 오래 지속되는 자격 증명으로 전환하는 데 사용되는 URI입니다. 이 URL은 일반적으로 /oauth1/access로 끝납니다.
  • 인증 핸드셰이크가 사용하는 Signature Method를 선택합니다. 호출에 사용할 oauth_signature_method를 지정합니다. 옵션은 다음과 같습니다:
    • HMAC-SHA1
    • HMAC-SHA256
    • HMAC-SHA512

대부분의 OAuth1 통합에서 앱, 서비스 또는 통합을 구성하여 이러한 필드의 대부분의 값을 생성해야 합니다. n8n의 OAuth Redirect URL을 해당 서비스의 리디렉션 URL 또는 리디렉션 URI로 사용합니다.

OAuth1OAuth1 인증 흐름에 대해 자세히 알아보세요.

OAuth2 사용#

앱 또는 서비스가 OAuth2 인증을 지원하는 경우 이 일반 인증을 사용합니다.

이 자격 증명을 구성하기 위한 요구 사항은 선택한 Grant Type에 따라 다릅니다. 각 부여 유형에 대한 자세한 내용은 OAuth 부여 유형을 참조하세요.

대부분의 OAuth2 통합에서 앱, 서비스 또는 통합을 구성해야 합니다. n8n의 OAuth Redirect URL을 해당 서비스의 리디렉션 URL 또는 리디렉션 URI로 사용합니다.

OAuth2에 대해 자세히 알아보세요.

Authorization Code 부여 유형#

Authorization Code 부여 유형을 사용하여 인증 코드를 액세스 토큰으로 교환합니다. 인증 흐름은 리디렉션 URL을 사용하여 사용자를 클라이언트로 반환합니다. 그런 다음 애플리케이션은 URL에서 인증 코드를 가져와 액세스 토큰을 요청하는 데 사용합니다. 자세한 내용은 Authorization Code Request를 참조하세요.

이 자격 증명을 구성하려면 Grant Type으로 Authorization Code를 선택합니다.

그런 다음 다음을 입력합니다:

  • Authorization URL
  • Access Token URL
  • Client ID: 로그인할 ID 또는 사용자 이름입니다.
  • Client Secret: 로그인에 사용하는 시크릿 또는 비밀번호입니다.
  • 선택 사항: 자격 증명에 대한 하나 이상의 Scope를 입력합니다. 지정하지 않으면 자격 증명이 클라이언트에서 사용 가능한 모든 스코프를 요청합니다.
  • 선택 사항: 일부 서비스는 더 많은 쿼리 매개변수를 요구합니다. 서비스가 요구하는 경우 Auth URI Query Parameters로 추가합니다.
  • Authentication 유형: 사용 사례에 가장 적합한 옵션을 선택합니다. 옵션은 다음과 같습니다:
    • Header: 자격 증명을 basic auth 헤더로 전송합니다.
    • Body: 요청 본문에 자격 증명을 전송합니다.
  • 선택 사항: Ignore SSL Issues 여부를 선택합니다. 켜면 SSL 유효성 검사가 실패해도 n8n이 연결합니다.

Client Credentials 부여 유형#

Client Credentials 부여 유형은 애플리케이션이 사용자를 대신하여서가 아닌 자체 리소스에 접근하기 위해 액세스 토큰을 요청할 때 사용합니다. 자세한 내용은 Client Credentials를 참조하세요.

이 자격 증명을 구성하려면 Grant Type으로 Client Credentials를 선택합니다.

그런 다음 다음을 입력합니다:

  • Access Token URL: OAuth2 흐름을 시작하기 위해 접속하는 URL입니다. 일반적으로 이 URL은 /token으로 끝납니다.
  • Client ID: 클라이언트에 로그인하는 데 사용하는 ID 또는 사용자 이름입니다.
  • Client Secret: 클라이언트에 로그인하는 데 사용하는 시크릿 또는 비밀번호입니다.
  • 선택 사항: 자격 증명에 대한 하나 이상의 Scope를 입력합니다. 대부분의 서비스는 Client Credentials 부여 유형에 대해 스코프를 지원하지 않으므로 서비스가 지원하는 경우에만 여기에 스코프를 입력합니다.
  • Authentication 유형: 사용 사례에 가장 적합한 옵션을 선택합니다. 옵션은 다음과 같습니다:
    • Header: 자격 증명을 basic auth 헤더로 전송합니다.
    • Body: 요청 본문에 자격 증명을 전송합니다.
  • 선택 사항: Ignore SSL Issues 여부를 선택합니다. 켜면 SSL 유효성 검사가 실패해도 n8n이 연결합니다.

PKCE 부여 유형#

PKCE(Proof Key for Code Exchange) 부여 유형은 CSRF 및 인증 코드 주입 공격을 방지하기 위한 Authorization Code 흐름의 확장입니다.

이 자격 증명을 구성하려면 Grant Type으로 PKCE를 선택합니다.

그런 다음 다음을 입력합니다:

  • Authorization URL
  • Access Token URL
  • Client ID: 로그인할 ID 또는 사용자 이름입니다.
  • Client Secret: 로그인에 사용하는 시크릿 또는 비밀번호입니다.
  • 선택 사항: 자격 증명에 대한 하나 이상의 Scope를 입력합니다. 지정하지 않으면 자격 증명이 클라이언트에서 사용 가능한 모든 스코프를 요청합니다.
  • 선택 사항: 일부 서비스는 더 많은 쿼리 매개변수를 요구합니다. 서비스가 요구하는 경우 Auth URI Query Parameters로 추가합니다.
  • Authentication 유형: 사용 사례에 가장 적합한 옵션을 선택합니다. 옵션은 다음과 같습니다:
    • Header: 자격 증명을 basic auth 헤더로 전송합니다.
    • Body: 요청 본문에 자격 증명을 전송합니다.
  • 선택 사항: Ignore SSL Issues 여부를 선택합니다. 켜면 SSL 유효성 검사가 실패해도 n8n이 연결합니다.

query auth 사용#

앱 또는 서비스가 인증을 단일 키/값 쿼리 매개변수로 전달하는 것을 지원하는 경우 이 일반 인증을 사용합니다. (여러 쿼리 매개변수의 경우 Custom Auth를 사용합니다.)

이 자격 증명을 구성하려면 다음을 입력합니다:

  • 쿼리 매개변수 키 또는 Name
  • 쿼리 매개변수 Value

custom auth 사용#

앱 또는 서비스가 인증을 여러 키/값 쿼리 매개변수로 전달하는 것을 지원하거나 다른 일반 인증 옵션보다 더 많은 유연성이 필요한 경우 이 일반 인증을 사용합니다.

Custom Auth 자격 증명은 자격 증명을 정의하기 위해 JSON 데이터를 기대합니다. headers, qs, body 또는 혼합을 사용할 수 있습니다. 시작하려면 아래 예시를 검토하세요.

두 개의 헤더 전송#

{
	"headers": {
		"X-AUTH-USERNAME": "username",
		"X-AUTH-PASSWORD": "password"
	}
}

Body#

{
	 "body" : {
		"user": "username",
		"pass": "password"
	}
}

Query string#

{
	"qs": {
		"appid": "123456",
		"apikey": "my-api-key"
	}
}

헤더 및 query string 전송#

{
	"headers": {
		"api-version": "202404"
	},
	"qs": {
		"apikey": "my-api-key"
	}
}

SSL 인증서 제공#

HTTP 요청과 함께 SSL 인증서를 전송할 수 있습니다. 노드에서 사용할 별도의 자격 증명으로 SSL 인증서를 생성합니다:

  1. HTTP Request 노드 Settings에서 SSL Certificates를 켭니다.
  2. Parameters 탭에서 Credential for SSL Certificates에 기존 SSL Certificate 자격 증명을 추가하거나 새 자격 증명을 생성합니다.

SSL Certificates 자격 증명을 구성하려면 다음을 추가해야 합니다:

  • 인증 기관 CA 번들
  • Certificate (CRT): 발급 CA에 따라 공개 키로 표시될 수도 있습니다.
  • Private Key (KEY)
  • 선택 사항: Private Key가 암호화된 경우 개인 키의 Passphrase를 입력합니다.

SSL 인증서가 단일 파일(예: .pfx 파일)에 있는 경우 파일을 열어 세부 정보를 복사하여 적절한 필드에 붙여넣어야 합니다:

  • 공개 키/CRT를 Certificate로 입력합니다.
  • Private Key/KEY를 해당 필드에 입력합니다.

HTTP Request 자격 증명

원문 보기
요약

이 자격 증명을 사용하여 다음 노드를 인증할 수 있습니다: 쿼리하려는 앱 또는 서비스에서 요구하는 인증 방법을 사용해야 합니다. SSL 인증서로 인증을 보호해야 하는 경우 필요한 정보는 SSL 인증서 제공을 참조하세요.

이 자격 증명을 사용하여 다음 노드를 인증할 수 있습니다:

사전 요구 사항#

쿼리하려는 앱 또는 서비스에서 요구하는 인증 방법을 사용해야 합니다.

SSL 인증서로 인증을 보호해야 하는 경우 필요한 정보는 SSL 인증서 제공을 참조하세요.

지원되는 인증 방법#

  • 미리 정의된 자격 증명 유형
  • Basic auth (일반 자격 증명 유형)
  • Custom auth (일반 자격 증명 유형)
  • Digest auth (일반 자격 증명 유형)
  • Header auth (일반 자격 증명 유형)
  • Bearer auth (일반 자격 증명 유형)
  • OAuth1 (일반 자격 증명 유형)
  • OAuth2 (일반 자격 증명 유형)
  • Query auth (일반 자격 증명 유형)

일반 자격 증명 유형에 대한 자세한 내용은 HTTP 인증을 참조하세요.

미리 정의된 자격 증명 유형

n8n은 연결하려는 서비스에 사용 가능한 자격 증명 유형이 있을 때마다 미리 정의된 자격 증명 유형을 사용하도록 권장합니다. 일반 자격 증명을 구성하는 것보다 자격 증명을 설정하고 관리하는 더 쉬운 방법을 제공합니다.

미리 정의된 자격 증명 유형을 사용하여 n8n이 플랫폼용 노드를 보유한 일부 API로 커스텀 작업을 수행할 수 있습니다. 예를 들어 n8n에는 Asana 노드가 있으며 HTTP Request 노드에서 Asana 자격 증명 사용을 지원합니다. 자세한 내용은 커스텀 작업을 참조하세요.

미리 정의된 자격 증명 유형 사용#

사전 정의된 자격증명 유형을 사용하려면:

  1. HTTP Request 노드를 열거나 워크플로우에 새로 추가합니다.
  2. **인증(Authentication)**에서 **사전 정의된 자격증명 유형(Predefined Credential Type)**을 선택합니다.
  3. **자격증명 유형(Credential Type)**에서 사용할 API를 선택합니다.
  4. 자격증명(Credential for ) 에서 다음을 선택할 수 있습니다:
    1. 해당 플랫폼의 기존 자격증명이 있으면 선택합니다.
    2. 새 자격증명을 만들려면 **새로 만들기(Create New)**를 선택합니다.

자세한 내용은 커스텀 API 작업을 참조하세요.

기본 인증(Basic Auth) 사용#

앱 또는 서비스가 기본 인증을 지원하는 경우 이 일반 인증을 사용합니다.

이 자격 증명을 구성하려면 다음을 입력합니다:

  • HTTP Request가 대상으로 하는 앱 또는 서비스에 접근하는 데 사용하는 사용자 이름(Username)
  • 해당 사용자 이름에 해당하는 비밀번호(Password)

다이제스트 인증(Digest Auth) 사용#

앱 또는 서비스가 다이제스트 인증을 지원하는 경우 이 일반 인증을 사용합니다.

이 자격 증명을 구성하려면 다음을 입력합니다:

  • HTTP Request가 대상으로 하는 앱 또는 서비스에 접근하는 데 사용하는 사용자 이름(Username)
  • 해당 사용자 이름에 해당하는 비밀번호(Password)

헤더 인증 사용하기#

앱 또는 서비스가 헤더 인증을 지원하는 경우 이 일반 인증 방식을 사용하세요.

이 자격증명을 구성하려면 다음을 입력하세요:

  • HTTP 요청이 대상으로 하는 앱 또는 서비스에 전달해야 할 헤더 Name
  • 헤더의 Value

HTTP 헤더에 대해 자세히 알아보세요.

Bearer 인증(Bearer Auth) 사용#

앱 또는 서비스가 Bearer 인증을 지원하는 경우 이 일반 인증을 사용합니다. 이 인증 유형은 실제로 NameAuthorization으로 설정되고 ValueBearer <token>으로 설정된 헤더 인증입니다.

이 자격 증명을 구성하려면 다음을 입력합니다:

  • HTTP 요청이 대상으로 하는 앱 또는 서비스에 전달해야 하는 Bearer 토큰(Bearer Token)

Bearer 인증에 대해 자세히 알아보세요.

OAuth1 사용#

앱 또는 서비스가 OAuth1 인증을 지원하는 경우 이 일반 인증을 사용합니다.

이 자격 증명을 구성하려면 다음을 입력합니다:

  • Authorization URL: Resource Owner Authorization URI라고도 합니다. 이 URL은 일반적으로 /oauth1/authorize로 끝납니다. 임시 자격 증명이 여기로 전송되어 사용자에게 인증 완료를 요청합니다.
  • Access Token URL: 임시 자격 증명에 대한 초기 요청에 사용되는 URI입니다. 이 URL은 일반적으로 /oauth1/request 또는 /oauth1/token으로 끝납니다.
  • Consumer Key: 클라이언트 키라고도 하며 사용자 이름과 같습니다. 호출에 사용할 oauth_consumer_key를 지정합니다.
  • Consumer Secret: 클라이언트 시크릿이라고도 하며 비밀번호와 같습니다.
  • Request Token URL: 인증 후 임시 자격 증명을 오래 지속되는 자격 증명으로 전환하는 데 사용되는 URI입니다. 이 URL은 일반적으로 /oauth1/access로 끝납니다.
  • 인증 핸드셰이크가 사용하는 Signature Method를 선택합니다. 호출에 사용할 oauth_signature_method를 지정합니다. 옵션은 다음과 같습니다:
    • HMAC-SHA1
    • HMAC-SHA256
    • HMAC-SHA512

대부분의 OAuth1 통합에서 앱, 서비스 또는 통합을 구성하여 이러한 필드의 대부분의 값을 생성해야 합니다. n8n의 OAuth Redirect URL을 해당 서비스의 리디렉션 URL 또는 리디렉션 URI로 사용합니다.

OAuth1OAuth1 인증 흐름에 대해 자세히 알아보세요.

OAuth2 사용#

앱 또는 서비스가 OAuth2 인증을 지원하는 경우 이 일반 인증을 사용합니다.

이 자격 증명을 구성하기 위한 요구 사항은 선택한 Grant Type에 따라 다릅니다. 각 부여 유형에 대한 자세한 내용은 OAuth 부여 유형을 참조하세요.

대부분의 OAuth2 통합에서 앱, 서비스 또는 통합을 구성해야 합니다. n8n의 OAuth Redirect URL을 해당 서비스의 리디렉션 URL 또는 리디렉션 URI로 사용합니다.

OAuth2에 대해 자세히 알아보세요.

Authorization Code 부여 유형#

Authorization Code 부여 유형을 사용하여 인증 코드를 액세스 토큰으로 교환합니다. 인증 흐름은 리디렉션 URL을 사용하여 사용자를 클라이언트로 반환합니다. 그런 다음 애플리케이션은 URL에서 인증 코드를 가져와 액세스 토큰을 요청하는 데 사용합니다. 자세한 내용은 Authorization Code Request를 참조하세요.

이 자격 증명을 구성하려면 Grant Type으로 Authorization Code를 선택합니다.

그런 다음 다음을 입력합니다:

  • Authorization URL
  • Access Token URL
  • Client ID: 로그인할 ID 또는 사용자 이름입니다.
  • Client Secret: 로그인에 사용하는 시크릿 또는 비밀번호입니다.
  • 선택 사항: 자격 증명에 대한 하나 이상의 Scope를 입력합니다. 지정하지 않으면 자격 증명이 클라이언트에서 사용 가능한 모든 스코프를 요청합니다.
  • 선택 사항: 일부 서비스는 더 많은 쿼리 매개변수를 요구합니다. 서비스가 요구하는 경우 Auth URI Query Parameters로 추가합니다.
  • Authentication 유형: 사용 사례에 가장 적합한 옵션을 선택합니다. 옵션은 다음과 같습니다:
    • Header: 자격 증명을 basic auth 헤더로 전송합니다.
    • Body: 요청 본문에 자격 증명을 전송합니다.
  • 선택 사항: Ignore SSL Issues 여부를 선택합니다. 켜면 SSL 유효성 검사가 실패해도 n8n이 연결합니다.

Client Credentials 부여 유형#

Client Credentials 부여 유형은 애플리케이션이 사용자를 대신하여서가 아닌 자체 리소스에 접근하기 위해 액세스 토큰을 요청할 때 사용합니다. 자세한 내용은 Client Credentials를 참조하세요.

이 자격 증명을 구성하려면 Grant Type으로 Client Credentials를 선택합니다.

그런 다음 다음을 입력합니다:

  • Access Token URL: OAuth2 흐름을 시작하기 위해 접속하는 URL입니다. 일반적으로 이 URL은 /token으로 끝납니다.
  • Client ID: 클라이언트에 로그인하는 데 사용하는 ID 또는 사용자 이름입니다.
  • Client Secret: 클라이언트에 로그인하는 데 사용하는 시크릿 또는 비밀번호입니다.
  • 선택 사항: 자격 증명에 대한 하나 이상의 Scope를 입력합니다. 대부분의 서비스는 Client Credentials 부여 유형에 대해 스코프를 지원하지 않으므로 서비스가 지원하는 경우에만 여기에 스코프를 입력합니다.
  • Authentication 유형: 사용 사례에 가장 적합한 옵션을 선택합니다. 옵션은 다음과 같습니다:
    • Header: 자격 증명을 basic auth 헤더로 전송합니다.
    • Body: 요청 본문에 자격 증명을 전송합니다.
  • 선택 사항: Ignore SSL Issues 여부를 선택합니다. 켜면 SSL 유효성 검사가 실패해도 n8n이 연결합니다.

PKCE 부여 유형#

PKCE(Proof Key for Code Exchange) 부여 유형은 CSRF 및 인증 코드 주입 공격을 방지하기 위한 Authorization Code 흐름의 확장입니다.

이 자격 증명을 구성하려면 Grant Type으로 PKCE를 선택합니다.

그런 다음 다음을 입력합니다:

  • Authorization URL
  • Access Token URL
  • Client ID: 로그인할 ID 또는 사용자 이름입니다.
  • Client Secret: 로그인에 사용하는 시크릿 또는 비밀번호입니다.
  • 선택 사항: 자격 증명에 대한 하나 이상의 Scope를 입력합니다. 지정하지 않으면 자격 증명이 클라이언트에서 사용 가능한 모든 스코프를 요청합니다.
  • 선택 사항: 일부 서비스는 더 많은 쿼리 매개변수를 요구합니다. 서비스가 요구하는 경우 Auth URI Query Parameters로 추가합니다.
  • Authentication 유형: 사용 사례에 가장 적합한 옵션을 선택합니다. 옵션은 다음과 같습니다:
    • Header: 자격 증명을 basic auth 헤더로 전송합니다.
    • Body: 요청 본문에 자격 증명을 전송합니다.
  • 선택 사항: Ignore SSL Issues 여부를 선택합니다. 켜면 SSL 유효성 검사가 실패해도 n8n이 연결합니다.

query auth 사용#

앱 또는 서비스가 인증을 단일 키/값 쿼리 매개변수로 전달하는 것을 지원하는 경우 이 일반 인증을 사용합니다. (여러 쿼리 매개변수의 경우 Custom Auth를 사용합니다.)

이 자격 증명을 구성하려면 다음을 입력합니다:

  • 쿼리 매개변수 키 또는 Name
  • 쿼리 매개변수 Value

custom auth 사용#

앱 또는 서비스가 인증을 여러 키/값 쿼리 매개변수로 전달하는 것을 지원하거나 다른 일반 인증 옵션보다 더 많은 유연성이 필요한 경우 이 일반 인증을 사용합니다.

Custom Auth 자격 증명은 자격 증명을 정의하기 위해 JSON 데이터를 기대합니다. headers, qs, body 또는 혼합을 사용할 수 있습니다. 시작하려면 아래 예시를 검토하세요.

두 개의 헤더 전송#

{
	"headers": {
		"X-AUTH-USERNAME": "username",
		"X-AUTH-PASSWORD": "password"
	}
}

Body#

{
	 "body" : {
		"user": "username",
		"pass": "password"
	}
}

Query string#

{
	"qs": {
		"appid": "123456",
		"apikey": "my-api-key"
	}
}

헤더 및 query string 전송#

{
	"headers": {
		"api-version": "202404"
	},
	"qs": {
		"apikey": "my-api-key"
	}
}

SSL 인증서 제공#

HTTP 요청과 함께 SSL 인증서를 전송할 수 있습니다. 노드에서 사용할 별도의 자격 증명으로 SSL 인증서를 생성합니다:

  1. HTTP Request 노드 Settings에서 SSL Certificates를 켭니다.
  2. Parameters 탭에서 Credential for SSL Certificates에 기존 SSL Certificate 자격 증명을 추가하거나 새 자격 증명을 생성합니다.

SSL Certificates 자격 증명을 구성하려면 다음을 추가해야 합니다:

  • 인증 기관 CA 번들
  • Certificate (CRT): 발급 CA에 따라 공개 키로 표시될 수도 있습니다.
  • Private Key (KEY)
  • 선택 사항: Private Key가 암호화된 경우 개인 키의 Passphrase를 입력합니다.

SSL 인증서가 단일 파일(예: .pfx 파일)에 있는 경우 파일을 열어 세부 정보를 복사하여 적절한 필드에 붙여넣어야 합니다:

  • 공개 키/CRT를 Certificate로 입력합니다.
  • Private Key/KEY를 해당 필드에 입력합니다.