OAuth2.0이란 무엇인가요?

OAuth2.0 살펴보기

강력하지만 종종 오해를 받는 인증 프로토콜인 OAuth2.0에 대해 알아보는 시간을 가져보겠습니다. 이 문서에서는 기본 사항을 설명하고, Tulip에서 지원되는 인증 흐름을 안내하며, 초기 커넥터의 구성에 대해 설명하고, 원활한 시작을 위한 빠른 팁을 공유합니다.

OAuth2.0은 복잡할 수 있으므로 간결하게 설명하기 위해 이 글에서는 몇 가지 세부적인 기술적 측면은 생략했습니다. Tulip의 새로 고침 토큰 처리, 범위 및 대상 관리, 사용자 지정 커넥터 구성에 대해 자세히 알아보고 싶으시다면 이 심층적인 OAuth2.0 기술 가이드를 확인하시기 바랍니다.

인증 유형

Tulip은 세 가지 OAuth2.0 인증 유형을 지원합니다: OAuth2.0(서비스 계정), OAuth2.0(사용자 자격증명), OAuth2.0(클라이언트 자격증명)입니다. 주요 차이점은 사용자 간에 자격 증명이 공유되는 방식과 OAuth 사양에 따라 실행되는 흐름에 있습니다. 고유한 OAuth 흐름에 대한 전체 목록과 설명은 여기에서 확인할 수 있습니다 (https://frontegg.com/blog/oauth-flows).

:::(Info) (참고)이전 Tulip 버전에서는 OAuth2.0(서비스 계정)을 OAuth2(관리자)라고 하고, OAuth2.0(사용자 자격 증명)을 OAuth2(운영자)라고 불렀습니다:::

인증 코드 흐름:

• OAuth2.0(서비스 계정): 커넥터 테스트 중에 제공된 자격 증명을 Tulip Player의 모든 사용자에 대해 사용합니다. 조직 전체에서 자격 증명을 공유하는 데 이상적입니다. 자격 증명이 만료되면 관리자 재인증이 필요합니다.
• OAuth2.0(사용자 자격 증명): Tulip Player에 로그인한 사용자를 기준으로 인증을 세분화합니다. 사용자가 인증하지 않았거나 인증이 만료되면 사용자는 Tulip Player 내에서 OAuth 플로우를 거치게 됩니다.

클라이언트 자격 증명 흐름:

• OAuth2.0(클라이언트 자격 증명): 이 부여 유형은 일반적으로 사용자를 대신하여 리소스에 액세스하는 대신 클라이언트의 자격 증명(클라이언트 ID 및 클라이언트 비밀)을 사용하여 인증 서버에 인증하여 액세스 토큰을 얻기 위해 Tulip에서 사용합니다.

기본 사항 공개

자세한 내용을 살펴보기 전에 먼저 환경에 대해 알아보고 커넥터 호스트와 그 기능에 대한 개요를 파악하는 것이 좋습니다.

OAuth2.0은 Tulip(클라이언트)이 비즈니스 시스템과 정체성을 확립하기 위한 메커니즘 역할을 합니다.

인증 코드 흐름

:::(Warning) (경고)사용자 인증 프로세스를 완료하려면 브라우저에서 팝업을 허용해야 합니다. 커넥터가 여러 환경으로 구성된 경우 인증 중에 각 환경마다 별도의 팝업 창이 열립니다.

Chrome에서 팝업이 사용 설정되어 있는지 확인하는 방법

1. Chrome을 열고 창 오른쪽 상단에 있는 점 3개 메뉴를 클릭합니다.
2. 드롭다운 메뉴에서 설정을 선택합니다.
3. 아래로 스크롤하여 개인정보 및 보안을 클릭합니다.
4. '개인정보 및 보안' 섹션 아래에서 사이트 설정을 클릭합니다.
5. 아래로 스크롤하여 팝업 및 리디렉션을 클릭합니다.
6. 토글이 팝업 허용으로 설정되어 있는지 확인하거나 팝업 표시가 허용된 사이트 목록에 해당 웹사이트를 수동으로 추가합니다.

팝업이 차단된 경우 팝업이 차단될 때마다 Chrome 주소창에 작은 아이콘이 표시됩니다. 이 아이콘을 클릭하면 튤립의 팝업을 빠르게 허용할 수 있습니다.:::

액세스 권한은 핸드셰이크를 통해 부여되며, Tulip은 가장 일반적인 OAuth 플로우인 인증 코드 플로우를 주로 지원합니다. 다음은 이 흐름이 어떻게 전개되는지 요약한 개요입니다:

1. 사용자는 커넥터를 저장하기 전에 테스트 버튼을 클릭하여 플로우를 시작합니다.
2. Tulip은 OAuth 공급자의 권한 부여 서버와 통신하여 클라이언트 ID, 범위(액세스하려는 대상) 및 기타 관련 세부 정보와 같은 특정 매개 변수를 공유합니다.
3. 인증 서버는 아래 예시와 같이 사용자에게 액세스 권한을 부여하라는 메시지를 표시합니다:

1. 사용자가 동의하면 인증 서버는 인증 코드를 생성하고 인증 창을 종료합니다.
2. 권한 부여 코드를 받은 Tulip은 토큰 엔드포인트에 도달하여 권한 부여 코드, 클라이언트 ID, 클라이언트 비밀 및 추가 속성을 제공하여 토큰을 안전하게 요청합니다.
3. 인증 코드의 유효성을 검사한 후 서버는 토큰과 선택적으로 새로 고침 토큰으로 응답합니다. 이 토큰은 사용자가 승인한 요청에 사용됩니다.
4. 이제 Tulip은 제공된 인증용 토큰을 사용하여 사용자를 대신하여 요청을 실행할 수 있습니다.

아래 다이어그램을 참조하여 실행 경로를 이해하세요:

클라이언트 자격 증명 흐름

클라이언트 자격 증명 플로우는 주로 두 비즈니스 시스템이 상호 작용하는 데 사용됩니다. 이 플로우는 한 번 구성한 다음 모든 사용자가 공유합니다.

1. 사용자는 커넥터를 저장하기 전에 테스트 버튼을 클릭하여 플로우를 시작합니다.
2. Tulip은 OAuth 공급자의 인증 서버와 통신하여 클라이언트 ID, 범위(액세스하려는 대상) 및 기타 관련 세부 정보와 같은 특정 매개 변수를 공유합니다.
3. 인증 서버는 클라이언트 ID와 클라이언트 비밀 번호가 정확하다고 가정하여 액세스 토큰을 반환합니다. 선택적으로 새로 고침 토큰도 반환할 수 있습니다. 이 토큰은 사용자가 승인한 요청에 사용됩니다.
4. 이제 Tulip은 제공된 인증용 토큰을 사용하여 사용자를 대신하여 요청을 실행할 수 있습니다.

OAuth 구성하기

:::(Warning) (온-프레미스 서비스)Tulip이 커넥터에 대한 인증을 실행하려면 권한 부여 및 토큰 엔드포인트에 클라우드에 액세스할 수 있어야 합니다:

인증 코드 URL

인증 코드 흐름의 2단계에서 Tulip이 연락하는 URL입니다. OAuth 공급자의 API 문서에서 찾을 수 있으며, 일반적으로 /auth 또는 /authorize로 끝납니다.

참고: 클라이언트 자격증명에는 이 필드가 존재하지 않습니다.

액세스 토큰 URL

인증 서버 응답 후, 인증용 토큰을 얻기 위해 액세스 토큰 URL로 요청이 이루어집니다. 일반적으로 /token으로 끝납니다.

참고: 이 필드는 클라이언트 자격증명에는 존재하지 않습니다.

클라이언트 ID 및 클라이언트 비밀

OAuth 공급자의 UI에서 생성된 클라이언트 ID는 인증 코드에 대한 초기 요청과 함께 전달됩니다. 클라이언트 ID와 클라이언트 비밀은 모든 토큰 요청과 함께 전달됩니다.

대상 및 범위

대상은 사용자가 액세스하려는 특정 자산을 지정하고 범위는 이러한 자산에 대해 원하는 작업을 정의합니다. 두 가지 모두 2단계의 인증 코드 요청 중에 전달됩니다.

추가 옵션

• 토큰 요청 데이터를 JSON으로 보내기: 토큰 URL로 전송되는 요청의 인코딩 유형을 변경합니다. 특정 통합에 필요한 경우 활성화합니다.
• 새로 고침 요청에 대한 인증 헤더 보내기: 활성화하면 새로 고침 요청에 추가 헤더를 추가합니다.
• 사용자 동의 프롬프트 건너뛰기: 인증 코드 요청의 프롬프트 속성을 제어합니다. 비활성화하면 동의로 설정되고, 활성화하면 로그인으로 설정되어 OAuth 공급자가 표시할 로그인 화면을 결정할 수 있습니다.

:::(Warning) (참고)일부 연동 서비스의 경우 프롬프트 속성을 제외하거나 없음으로 설정하세요. 자세한 기능은 support@tulip.co 참조:::

더 자세히 알아보기

더 많은 인사이트를 얻고 싶으신가요? 다음 문서를 살펴보세요:

• OAuth2.0 구성 및 기술 세부 사항
• 여러 환경에서 커넥터 기능을 실행하는 방법