HTTP Request 자격 증명
n8n v2.29이 자격 증명을 사용하여 다음 노드를 인증할 수 있습니다: 조회하려는 앱이나 서비스에서 요구하는 인증 방식을 사용해야 합니다. SSL 인증서로 인증을 보호해야 하는 경우, 필요한 정보는 SSL 인증서 제공을 참고하세요.
이 자격 증명을 사용하여 다음 노드를 인증할 수 있습니다:
전제 조건#
조회하려는 앱이나 서비스에서 요구하는 인증 방식을 사용해야 합니다.
SSL 인증서로 인증을 보호해야 하는 경우, 필요한 정보는 SSL 인증서 제공을 참고하세요.
지원되는 인증 방식#
- 사전 정의된 자격 증명 유형
- Basic 인증(일반 자격 증명 유형)
- Custom 인증(일반 자격 증명 유형)
- Digest 인증(일반 자격 증명 유형)
- Header 인증(일반 자격 증명 유형)
- Bearer 인증(일반 자격 증명 유형)
- OAuth1(일반 자격 증명 유형)
- OAuth2(일반 자격 증명 유형)
- Query 인증(일반 자격 증명 유형)
일반 자격 증명 유형에 대한 자세한 내용은 HTTP 인증을 참고하세요.
사전 정의된 자격 증명 유형
연결하려는 서비스에 사용 가능한 자격 증명 유형이 있는 경우, n8n은 사전 정의된 자격 증명 유형을 사용하는 것을 권장합니다. 일반 자격 증명을 구성하는 것보다 더 쉬운 방식으로 자격 증명을 설정하고 관리할 수 있습니다.
n8n에 해당 플랫폼용 노드가 있는 일부 API의 경우, 사전 정의된 자격 증명 유형을 사용하여 커스텀 작업을 수행할 수 있습니다. 예를 들어 n8n에는 Asana 노드가 있으며, HTTP Request 노드에서 Asana 자격 증명을 사용하는 것을 지원합니다. 자세한 내용은 커스텀 작업을 참고하세요.
사전 정의된 자격 증명 유형 사용하기#
이 섹션의 상세 내용은 n8n 공식 문서를 참조하세요.
자세한 내용은 커스텀 API 작업을 참고하세요.
이 섹션의 상세 내용은 n8n 공식 문서를 참조하세요.
이 섹션의 상세 내용은 n8n 공식 문서를 참조하세요.
이 섹션의 상세 내용은 n8n 공식 문서를 참조하세요.
이 섹션의 상세 내용은 n8n 공식 문서를 참조하세요.
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 통합의 경우, 이 필드 값 대부분을 생성하려면 앱, 서비스 또는 통합을 구성해야 합니다. 이러한 서비스의 리디렉션 URL 또는 리디렉션 URI로 n8n의 OAuth Redirect URL을 사용하세요.
OAuth1 및 OAuth1 인증 흐름에 대해 자세히 알아보세요.
OAuth2 사용하기#
앱이나 서비스가 OAuth2 인증을 지원하는 경우 이 일반 인증을 사용하세요.
이 자격 증명을 구성하는 데 필요한 요구 사항은 선택한 Grant Type에 따라 달라집니다. 각 그랜트 유형에 대한 자세한 내용은 OAuth Grant Types를 참고하세요.
대부분의 OAuth2 통합의 경우, 앱, 서비스 또는 통합을 구성해야 합니다. 이러한 서비스의 리디렉션 URL 또는 리디렉션 URI로 n8n의 OAuth Redirect URL을 사용하세요.
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 인증 헤더로 전송합니다.
- 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 인증 헤더로 전송합니다.
- 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 인증 헤더로 전송합니다.
- Body: 자격 증명을 요청 본문에 전송합니다.
- 선택 사항: Ignore SSL Issues 사용 여부를 선택합니다. 켜져 있으면 SSL 검증에 실패하더라도 n8n이 연결합니다.
Query 인증 사용하기#
앱이나 서비스가 단일 키/값 쿼리 파라미터로 인증을 전달하는 것을 지원하는 경우 이 일반 인증을 사용하세요. (여러 개의 쿼리 파라미터가 필요한 경우 Custom Auth를 사용하세요.)
이 자격 증명을 구성하려면 다음을 입력합니다:
- 쿼리 파라미터 키 또는 Name
- 쿼리 파라미터 Value
Custom 인증 사용하기#
앱이나 서비스가 여러 개의 키/값 쿼리 파라미터로 인증을 전달하는 것을 지원하거나, 다른 일반 인증 옵션보다 더 많은 유연성이 필요한 경우 이 일반 인증을 사용하세요.
Custom Auth 자격 증명은 자격 증명을 정의하기 위해 JSON 데이터를 필요로 합니다. headers, qs, body 또는 이들의 조합을 사용할 수 있습니다. 시작하려면 아래 예시를 참고하세요.
헤더 두 개 전송하기#
{
"headers": {
"X-AUTH-USERNAME": "username",
"X-AUTH-PASSWORD": "password"
}
}
Body#
{
"body" : {
"user": "username",
"pass": "password"
}
}
쿼리 문자열#
{
"qs": {
"appid": "123456",
"apikey": "my-api-key"
}
}
헤더와 쿼리 문자열 함께 전송하기#
{
"headers": {
"api-version": "202404"
},
"qs": {
"apikey": "my-api-key"
}
}
SSL 인증서 제공#
HTTP 요청과 함께 SSL 인증서를 전송할 수 있습니다. 노드에서 사용할 SSL 인증서를 별도의 자격 증명으로 생성하세요:
- HTTP Request 노드의 Settings에서 SSL Certificates를 켭니다.
- Parameters 탭에서 Credential for SSL Certificates에 기존 SSL Certificate 자격 증명을 추가하거나 새로 만듭니다.
SSL Certificates 자격 증명을 구성하려면 다음을 추가해야 합니다:
- 인증 기관(Certificate Authority) CA 번들
- Certificate(CRT): 발급 CA와 인증서 형식 방식에 따라 Public Key로 표시될 수도 있습니다
- Private Key(KEY)
- 선택 사항: Private Key가 암호화된 경우, 프라이빗 키의 Passphrase를 입력합니다.
SSL 인증서가 단일 파일(예: .pfx 파일)에 있는 경우, 해당 파일을 열어 세부 정보를 복사한 후 적절한 필드에 붙여넣어야 합니다:
- Public Key/CRT를 Certificate로 입력합니다
- Private Key/KEY를 해당 필드에 입력합니다