일반적인 REST API 인증 방법 설명

자동화 및 오케스트레이션을 구현할 때 API 인증 방식에 대한 이해는 매우 중요합니다. 대부분의 제품에는 자체적인 인증 메커니즘이 있을 가능성이 높습니다. 이러한 API와의 통신을 자동화하려면 다양한 인증 방식의 차이점을 정확히 파악해야 합니다. 이 블로그 게시물에서는 세 가지 API 인증 방식을 분석하여 이해를 돕고자 합니다.

사용자 이름 및 비밀번호 인증

REST API에서 가장 흔하게 사용되는 인증 방법 중 하나는 사용자 이름과 비밀번호를 이용한 인증입니다. 사용자 이름과 비밀번호를 사용하는 인증 방식에는 여러 가지가 있지만, 가장 일반적인 것은 HTTP 기본 인증입니다. API 사용 경험이 있는 사람에게는 간단하지만, 초보자에게는 작동 방식과 사용 방법을 이해하기 어려울 수 있습니다.

당 RFC2617, 기본 인증을 사용하여 HTTP 요청을 보내려면 사용자 이름과 비밀번호를 콜론으로 구분하여 base64로 인코딩한 문자열이 필요합니다. 이 문자열 앞에는 `Basic`이라는 문자열과 공백 하나가 추가됩니다. 이를 좀 더 명확하게 이해하기 위해 다음 예시를 살펴보겠습니다.

사용자 이름: first.last

비밀번호: my5uper5ecretP@ssw0rd

위 예시와 같은 사용자 이름과 비밀번호가 있다고 가정해 보세요. 이러한 정보를 API에 대한 HTTP 요청의 일부로 사용하려면 먼저 콜론으로 두 정보를 연결해야 합니다.

first.last:my5uper5ecretP@ssw0rd

그 작업이 완료되면 해당 값을 base64로 인코딩해야 합니다. 파이썬에서는 다음과 같이 할 수 있습니다.

base64를 가져옵니다.

auth_string = base64.b64encode(b':'.join(('first.last'.encode('latin1'), 'my5uper5ecretP@ssw0rd'.encode('latin1')))).strip()

auth_string 변수를 출력하면 다음과 같은 값이 표시됩니다.

b'Zmlyc3QubGFzdDpteTV1cGVyNWVjcmV0UEBzc3cwcmQ='’

이제 인코딩된 문자열을 얻었으므로, 이 변수 앞에 인증 방식 문자열(Basic)을 추가합니다. 전체 변수 문자열은 다음과 같아야 합니다.

기본 Zmlyc3QubGFzdDpteTV1cGVyNWVjcmV0UEBzc3cwcmQ=

이 문자열이 생성되면 HTTP 요청의 특정 HTTP 헤더에 추가됩니다. 이 헤더는 인증에 사용되는 특별한 헤더입니다. 짐작하셨겠지만, 이 헤더의 이름은 Authorization입니다. 편리하죠?

다음은 기본 인증을 사용하는 cURL 명령의 예입니다.

AUTH=$(echo -ne "$BASIC_AUTH_USER:$BASIC_AUTH_PASSWORD" | base64 --wrap 0) curl \ --header "Content-Type: application/json" \ --header "Authorization: Basic $AUTH" \ --request POST \ --data '{"key1":"value1", "key2":"value2"}' \ https://example.com/

JWT 인증

JWT(JSON Web Token) 인증은 토큰 기반 인증의 일반적인 형태입니다. RFC 7519. JWT 인증은 헤더, 페이로드, 서명의 세 가지 주요 부분으로 구성됩니다. 이 세 부분 각각은 base64로 인코딩되어 인증을 위한 HTTP 요청과 함께 전송됩니다.

JWT 클레임 세트는 JSON 객체에 지정된 하나 이상의 클레임으로 구성됩니다. 클레임 세트의 각 클레임은 고유한 키와 그에 대응하는 값을 가집니다. 예를 들어, 일반적인 JWT 클레임 세트 구조는 다음과 같습니다.

{ “iss”: “josh”, “exp”: 1617221146, “https://api.mycompany.com/some...”: true }

각 키와 값은 고유해야 하며, 클레임 세트 내에서 개별적인 클레임으로 간주됩니다. 이러한 지정된 키는 임의로 정할 수 있으며 RFC 표준에서 요구하는 사항은 아닙니다. 즉, JWT 인증에서 클레임 세트의 구조는 사용 중인 API/서비스에 따라 달라집니다.

헤더 및 서명 값과 마찬가지로, JWT 클레임(페이로드)을 정의하고 나면 해당 값은 base64로 인코딩됩니다. 이러한 값은 다음에서 테스트할 수 있습니다. https://jwt.io 또한.

OAuth2 인증

OAuth2 인증은 동일한 엔드포인트에 대해 다양한 인증 방식(플로우)을 지원한다는 단순한 사실 때문에 매우 인기를 얻고 있습니다. 이를 통해 개발자는 웹 애플리케이션, 데스크톱 애플리케이션, 모바일 장치 등 다양한 상황에 맞는 인증 권한을 제공하는 강력한 서비스를 구축할 수 있으며, 각 상황에 대해 완전히 다른 인증 메커니즘을 지원할 필요 없이 몇 가지 세부 정보만 변경하면 됩니다.

OAuth2 인증 개념을 더 잘 이해할 수 있도록 네 가지 핵심 구성 요소를 보여주는 다이어그램을 만들었습니다.

1. 접근 권한이 필요한 사용자 또는 시스템

2. 권한 부여를 담당하는 서버

3. 권한 부여 서버를 통해 접근 권한이 부여된 애플리케이션

4. 그러면 해당 애플리케이션은 그 권한에 따라 데이터에 접근합니다.

OAuth2에 대해 더 자세히 알고 싶으시다면, 제가 작성한 OAuth2에 대한 상세한 설명이 담긴 3부작 시리즈를 여기에서 확인해 보세요.

• 파트 1: 엔드포인트 및 애플리케이션 유형

• 파트 2: 신청서 등록

• 파트 3: Microsoft Graph API 사용하기

인증 유형을 살펴보면 OAuth2와 JWT는 Basic 인증보다 보안성이 높으며, 특히 EDR, SIEM 등의 제품을 사용할 때 API에서 이러한 인증 방식을 접하게 될 가능성이 높습니다.

REST API 인증에는 이 외에도 다양한 유형과 위에서 언급한 방법의 변형이 있지만, 이 글을 통해 API에서 가장 일반적으로 사용되는 세 가지 인증 방법을 이해하는 데 도움이 되었기를 바랍니다.