최종 사용자 자격 증명을 사용하면 고정된 자격 증명이 아니라 워크플로를 트리거한 사람의 자격 증명으로 워크플로가 실행됩니다. 프로젝트 관리자가 하나의 자격 증명을 템플릿으로 생성하면, 각 사용자가 자신의 계정을 연결합니다. n8n은 각 사용자가 연결한 계정을 사용하며 사용자의 데이터를 비공개로 유지합니다.

고정 자격 증명을 사용하면 워크플로를 실행하는 모든 사람이 동일한 계정을 사용하게 되어, 한 사람의 접근 권한과 데이터가 다른 모든 사람에게 노출될 수 있습니다. 최종 사용자 자격 증명은 각 사용자에게 자신만의 연결을 제공하고 실행 데이터를 격리합니다.

최종 사용자 자격 증명이란#

자격 증명을 생성하거나 편집할 때 Credential type을 선택합니다:

• Fixed credential(고정 자격 증명): 워크플로를 실행하는 사람과 관계없이 동일한 자격 증명을 사용합니다. 기본값입니다.
• End-user credential(최종 사용자 자격 증명): 실행 시점에 각 사용자의 자격 증명을 사용합니다. 해당 사용자만 자신의 자격 증명을 보고 사용할 수 있습니다.

최종 사용자 자격 증명은 템플릿입니다. 이를 생성한 사람이 연결을 한 번 설정합니다. 예를 들어 Gmail의 OAuth 앱 세부 정보를 설정합니다. 접근 권한이 있는 모든 사용자는 해당 템플릿을 사용해 자신의 계정을 연결합니다. 각 연결은 그것을 만든 사용자에게 속합니다: 오직 그 사용자만 이를 사용할 수 있고, 그 사용자만 반환되는 데이터를 볼 수 있습니다.

예시#

수동 트리거로 Gmail에서 메시지를 읽어 Slack으로 요약을 전송하는 워크플로를 구축한다고 가정해보세요. Gmail용 최종 사용자 자격 증명을 템플릿으로 생성합니다. 사용자 A가 워크플로를 실행하면 n8n은 사용자 A의 받은편지함을 읽습니다. 사용자 B가 실행하면 n8n은 사용자 B의 받은편지함을 읽습니다. 각 사용자는 자신의 데이터만 볼 수 있습니다.

작동 방식#

노드에서 자격 증명 드롭다운을 사용해 자격 증명을 선택하는 것은 평소와 동일합니다. 노드에 별도의 설정이 없습니다. 노드 동작은 자격 증명 유형에 따라 달라집니다:

• 고정 자격 증명을 사용하면 노드는 항상 그래왔던 대로 동작합니다.
• 최종 사용자 자격 증명을 사용하면 노드는 트리거한 사용자의 계정을 사용한다는 것을 표시하고, 아직 연결하지 않은 경우 연결하도록 안내합니다.

실행 시점에 n8n은 워크플로를 트리거한 사용자의 연결된 계정으로 자격 증명을 확인(resolve)합니다. 워크플로에 접근 권한이 있는 모든 사용자는 자신의 신원(identity) 관점에서 노드를 봅니다. 계정을 연결했다면 그 연결이 실행되고, 그렇지 않다면 워크플로를 트리거하기 전에 연결해야 합니다.

하나의 워크플로에서 고정 자격 증명과 최종 사용자 자격 증명을 혼합해 사용할 수 있습니다. 예를 들어 각 사용자의 개인 Google 캘린더는 최종 사용자 자격 증명으로 읽고, 결과는 고정 자격 증명을 사용하는 공유 팀 Slack 계정을 통해 전송할 수 있습니다.

요구 사항 및 제한 사항#

• 엔터프라이즈 전용: 최종 사용자 자격 증명에는 엔터프라이즈 플랜이 필요합니다.
• 생성 권한 제한: 기본적으로 프로젝트 관리자만 최종 사용자 자격 증명을 생성할 수 있습니다. 커스텀 역할을 통해 다른 사용자에게 이 권한을 부여할 수 있습니다. 생성 권한을 제한하면 자격 증명 관리가 중앙화됩니다: 여러 사용자가 각자 설정하는 대신, 관리자가 템플릿을 한 번 설정해 필요한 프로젝트에 공유합니다.
• OAuth 자격 증명만 지원: 최종 사용자 자격 증명은 OAuth 기반 자격 증명 유형만 지원합니다.
• 사용자당 하나의 연결: 각 사용자는 최종 사용자 자격 증명 템플릿당 하나의 계정만 연결할 수 있습니다.
• 지원되는 트리거: 최종 사용자 자격 증명 확인(resolution)은 수동 트리거, Chat Hub, MCP Server Trigger에서 작동합니다.

최종 사용자 자격 증명 생성하기#

1. 자격 증명을 생성하거나 기존 자격 증명을 엽니다.
2. Credential type 아래에서 End-user credential을 선택합니다.
3. 연결을 설정합니다. OAuth 자격 증명의 경우 서비스에 등록할 Client ID, Client Secret, OAuth Redirect URL을 입력합니다.
4. Save를 선택합니다.

프로젝트에 접근 권한이 있는 사용자는 이제 이 자격 증명에 자신의 계정을 연결할 수 있습니다.

계정 연결하기#

워크플로에서 최종 사용자 자격 증명을 사용하기 전에, 템플릿에 자신의 계정을 연결하세요. 다음 위치에서 연결할 수 있습니다:

• 노드: 최종 사용자 자격 증명을 사용하는 노드를 열면 계정을 연결했는지 여부가 표시됩니다. 연결하지 않았다면 Connect를 선택하세요.
• 자격 증명: 최종 사용자 자격 증명을 열고 자격 증명 모달에서 계정을 연결합니다.
• 자격 증명 목록: 프로젝트의 Credentials 목록에서 최종 사용자 자격 증명 카드에 Connect 옵션이 있습니다.

계정의 OAuth 흐름을 완료합니다. 연결되면 노드에 계정이 표시됩니다. 예: Connected as you@example.com.

여러분의 연결은 비공개입니다. 다른 사용자는 동일한 템플릿에 자신의 계정을 연결하며, 여러분의 계정을 절대 사용하지 않습니다.

실행 데이터와 개인정보 보호#

워크플로 실행이 최종 사용자 자격 증명을 사용하면, 해당 워크플로의 실행에 접근 권한이 있는 모든 사람에게 실행 메타데이터가 표시됩니다: 상태, 실행 시각, 최종 사용자 자격 증명을 사용했다는 사실입니다. 달라지는 것은 내부 데이터를 볼 수 있는 사람입니다.

연결된 계정으로 워크플로를 트리거한 사용자만 해당 노드의 입력 및 출력 데이터를 볼 수 있으며, 여기에는 연결된 서비스에서 반환된 데이터가 포함됩니다. 인스턴스 관리자를 포함한 다른 모든 사람에게는 해당 노드의 출력이 마스킹되어 표시됩니다.

관리자에게 보이는 정보#

관리자는 최종 사용자 자격 증명 템플릿이 존재하고 여기에 연결이 있다는 것을 볼 수 있습니다. 예를 들어 최종 사용자 자격 증명을 삭제할 때, 관리자는 몇 개의 사용자 연결이 있는지 볼 수 있습니다. 관리자가 볼 수 있는 것은 그 개수뿐입니다. 관리자는 다음을 할 수 없습니다:

• 개별 연결에 대한 어떤 정보도 볼 수 없습니다
• 연결의 비밀 정보를 볼 수 없습니다
• 자신의 워크플로에서 다른 사용자의 연결된 계정을 사용할 수 없습니다
• 다른 사용자의 연결로 실행된 결과의 마스킹된 출력을 볼 수 없습니다

공유 방식은 일반 자격 증명과 동일하지만, 연결된 계정이 아니라 템플릿만 공유됩니다. 관리자는 다른 프로젝트나 다른 사용자에게 공유할 수 있으며, 각 수신자는 자신의 계정을 연결합니다.

프로젝트 간 최종 사용자 자격 증명 공유하기#

표준 자격 증명 공유 메커니즘을 사용해 최종 사용자 자격 증명을 다른 프로젝트에 공유하세요. 공유되는 것은 템플릿이며 연결이 아닙니다. 다른 프로젝트의 사용자에게는 자신의 계정을 연결하는 옵션이 표시됩니다. 원래 소유자의 연결을 받지는 않습니다.

각 사용자는 템플릿당 한 번만 연결합니다. 이 단일 연결은 템플릿이 공유된 모든 프로젝트에서 해당 사용자에 대해 확인(resolve)되므로, 각 프로젝트마다 다시 연결할 필요가 없습니다.

좋은 방법은 Gmail, Linear, Jira, Google Sheets와 같은 최종 사용자 자격 증명을 하나의 프로젝트에서 생성한 다음, 이를 필요로 하는 다른 프로젝트에 공유하는 것입니다. 각 프로젝트는 동일한 템플릿을 받고, 각 사용자의 하나의 연결이 모든 프로젝트에서 작동합니다.

관련 리소스#

• 자격 증명 생성 및 편집
• 자격 증명 안전하게 공유하기
• RBAC 역할 유형