HTTP Request 자격 증명
n8n v2.42요약
이 자격 증명을 사용하여 다음 노드를 인증할 수 있습니다: 이 섹션의 상세 내용은 n8n 공식 문서를 참조하세요. 조회하려는 앱이나 서비스에서 요구하는 인증 방식을 사용해야 합니다. SSL 인증서로 인증을 보호해야 하는 경우, 필요한 정보는 SSL 인증서 제공을 참고하세요.
이 자격 증명을 사용하여 다음 노드를 인증할 수 있습니다:
이 섹션의 상세 내용은 n8n 공식 문서를 참조하세요.
전제 조건#
조회하려는 앱이나 서비스에서 요구하는 인증 방식을 사용해야 합니다.
SSL 인증서로 인증을 보호해야 하는 경우, 필요한 정보는 SSL 인증서 제공을 참고하세요.
지원되는 인증 방식#
- 사전 정의된 자격 증명 유형
- Basic 인증(일반 자격 증명 유형)
- Custom 인증(일반 자격 증명 유형)
- Digest 인증(일반 자격 증명 유형)
- Header 인증(일반 자격 증명 유형)
- Bearer 인증(일반 자격 증명 유형)
- OAuth1(일반 자격 증명 유형)
- OAuth2(일반 자격 증명 유형)
- Query 인증(일반 자격 증명 유형)
- Simplified Custom Auth(일반 자격 증명 유형)
일반 자격 증명 유형에 대한 자세한 내용은 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로 끝납니다. n8n은 사용자에게 인증을 완료하도록 요청하기 위해 임시 자격 증명을 여기로 보냅니다. - 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"
}
}
Simplified Custom Auth 사용하기#
앱이나 서비스가 헤더, 쿼리 파라미터 또는 요청 본문에 고정된 인증 값을 요구하며, 비밀 값을 요청 정의와 분리해 보관하려는 경우 이 일반 인증을 사용하세요.
Simplified Custom Auth는 Custom 인증과 비슷하게, 해당 자격 증명을 사용하는 모든 요청에 n8n이 병합하는 JSON을 사용합니다. 차이점은 이 JSON이 비밀 값 자체가 아니라 {{placeholder}} 마커가 들어 있는 템플릿이라는 것입니다. 자격 증명 양식에는 플레이스홀더마다 필드가 하나씩 표시되며, n8n은 요청을 보낼 때 각 마커를 해당 필드의 값으로 바꿉니다.
이렇게 나눈 이유는 n8n Assistant가 설정 부분을 대신 준비할 수 있게 하기 위해서입니다. n8n Assistant가 전용 n8n 자격 증명이 없는 서비스용 워크플로를 만들 때 이 자격 증명 유형을 생성합니다. 서비스의 API 문서를 바탕으로 템플릿, 필드, 테스트 URL을 준비하므로 사용자는 비밀 값만 양식에 붙여넣으면 됩니다. 또한 서비스의 API 호스트를 기록하여, n8n이 같은 서비스를 호출하는 노드에만 이 자격 증명을 제안하도록 합니다.
자격 증명을 직접 설정할 수도 있습니다. 자격 증명 모달에서 Edit setup을 선택한 다음 다음을 입력합니다:
- Auth template: 이 자격 증명을 사용하는 모든 요청에 n8n이 병합하는 JSON입니다.
headers,qs,body또는 이들의 조합을 사용할 수 있으며, 비밀 값이나 계정별 값이 들어갈 자리에{{placeholder}}마커를 넣습니다. 템플릿에 실제 값을 넣지 마세요. - 각 플레이스홀더의 Fields 설정: Label, 값이 Secret(마스킹됨)인지 Plain text인지, Required인지 여부, 그리고 형식과 같이 기대하는 값을 설명하는 선택 사항인 Hint.
- 선택 사항: Test URL: 자격 증명을 저장할 때 인증을 적용해 n8n이 호출하여 자격 증명이 작동하는지 확인하는 GET 엔드포인트입니다. 계정 또는 프로필 엔드포인트처럼 부작용이 없고 과금 대상 작업을 절대 발생시키지 않는 엔드포인트를 선택하세요.
- 선택 사항: Accepted status codes: 자격 증명을 테스트할 때 2xx 응답과 함께 성공으로 처리할 상태 코드입니다. 예를 들어 권한 범위가 제한된 유효한 키에 대해 403을 반환하는 서비스의 경우
403을 지정합니다. - 선택 사항: Documentation URL: 비밀 값을 만들거나 복사하는 제공자 페이지입니다. 자격 증명 양식에는 표시되지 않으며, n8n Assistant가 정확한 페이지를 안내하는 데 사용합니다.
그런 다음 양식으로 돌아가 각 필드에 값을 입력합니다. n8n은 저장 후 값을 마스킹합니다.
헤더로 API 키 전송하기#
Bearer 토큰을 전송하는 템플릿입니다:
{
"headers": {
"Authorization": "Bearer {{api_key}}"
}
}
자격 증명 양식에는 api_key 필드가 하나 표시됩니다. 노드가 요청을 보낼 때 n8n은 마커를 필드의 값으로 바꾸며, 그 결과 Authorization: Bearer <your-api-key> 헤더가 만들어집니다.
필수 필드가 비어 있으면 서비스에 마커 문자열을 그대로 보내는 대신 요청이 오류와 함께 실패합니다. 선택 필드가 비어 있으면 n8n은 해당 필드를 사용하는 템플릿 항목을 요청에서 제거합니다.
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를 해당 필드에 입력합니다