메뉴
Amazon Simple Storage Service
개발자 안내서 (API Version 2006-03-01)

REST 요청 서명 및 인증

참고

이 항목에서는 서명 버전 2를 사용한 요청 인증을 설명합니다. Amazon S3는 최신 서명 버전 4를 지원합니다. 최신 서명 버전은 모든 리전에서 지원되며 2014년 1월 30일 이후에는 모든 새 리전에서 서명 버전 4만 지원합니다. 자세한 내용은 Amazon Simple Storage Service API Reference요청 인증(AWS 서명 버전 4)을 참조하십시오.

인증은 시스템에 대한 자격 증명을 입증하는 과정입니다. 자격 증명은 Amazon S3 액세스 제어 결정에서 중요한 요소입니다. 요청은 요청자의 자격 증명에 따라 부분적으로 허용 또는 거부됩니다. 예를 들어 버킷을 만들 수 있는 권한은 등록된 개발자용으로 예약되어 있고(기본 설정) 버킷의 객체를 만들 수 있는 권한은 해당 버킷 소유자용으로 예약되어 있습니다. 개발자는 이러한 권한을 호출하는 요청을 생성하여 요청을 인증함으로써 시스템에 자격 증명을 입증해야 합니다. 이 단원에서 그 방법을 설명합니다.

참고

이 단원의 내용은 HTTP POST에 적용되지 않습니다. 자세한 내용은 POST를 사용한 브라우저 기반 업로드(AWS 서명 버전 2) 단원을 참조하십시오.

Amazon S3 REST API는 키 참조 HMAC(Hash Message Authentication Code)를 기반으로 하는 사용자 지정 HTTP 체계를 인증에 사용합니다. 요청을 인증하려면 먼저 요청의 선택된 요소를 연결하여 문자열을 구성합니다. 그 다음 AWS 보안 액세스 키를 사용하여 해당 문자열의 HMAC를 계산합니다. 이 프로세스를 약식으로 "요청 서명"이라고 부르며, 이 프로세스는 실제 서명의 보안 속성을 시뮬레이션하기 때문에 HMAC 알고리즘의 결과를 서명이라고 부릅니다. 마지막으로 이 단원에서 설명된 구문을 사용하여 이 서명을 요청의 파라미터로 추가합니다.

인증된 요청을 받으면 시스템은 요청된 AWS 보안 액세스 키를 가져와 동일한 방식으로 사용하여 받은 메시지에 대한 서명을 계산합니다. 그런 다음 계산한 서명을 요청자가 제시한 서명과 비교합니다. 두 서명이 일치하면 요청자가 AWS 보안 액세스 키에 대한 액세스 권한을 가진고 있는 것으로 간주되어 키가 발행된 보안 주체의 권한으로 동작합니다. 두 서명이 일치하지 않으면 요청이 삭제되고 시스템에서 오류 메시지를 반환합니다.

예 인증된 Amazon S3 REST 요청

Copy
GET /photos/puppy.jpg HTTP/1.1 Host: johnsmith.s3.amazonaws.com Date: Mon, 26 Mar 2007 19:37:58 +0000 Authorization: AWS AKIAIOSFODNN7EXAMPLE:frJIUN8DYpKDtOLCwo//yllqDzg=

Using Temporary Security Credentials

임시 보안 자격 증명을 사용하여 요청을 서명할 경우(요청 만들기 참조), x-amz-security-token 헤더를 추가하여 요청에 해당 보안 토큰을 포함해야 합니다.

AWS Security Token Service API를 사용하여 임시 보안 자격 증명을 받을 경우에는 응답에 임시 보안 자격 증명과 세션 토큰이 포함됩니다. Amazon S3로 요청을 보낼 때 x-amz-security-token 헤더에 세션 토큰 값을 제공합니다. IAM에서 제공하는 AWS Security Token Service에 대한 자세한 내용은 AWS Security Token Service API Reference 가이드작업을 참조하십시오.

Authentication 헤더

Amazon S3 REST API는 표준 HTTP Authorization 헤더를 사용하여 인증 정보를 전달합니다. 표준 헤더의 이름은 아쉽게도 인증이 아닌 인증 정보만을 나타냅니다. Amazon S3 인증 체계에서 Authorization 헤더는 다음 형식을 갖습니다.

Copy
Authorization: AWS AWSAccessKeyId:Signature

개발자는 등록 시 AWS 보안 액세스 키 ID와 AWS 보안 액세스 키를 발급받습니다. 요청 인증에 대해 AWSAccessKeyId 요소는 서명을 계산할 때 사용된 액세스 키 ID를 식별하고, 요청을 하는 개발자를 간접적으로 식별합니다.

Signature 요소는 요청의 선택된 요소에 대한 RFC 2104 HMAC-SHA1이므로 Authorization 헤더의 Signature 부분은 요청마다 다양합니다. 시스템에서 계산한 요청 서명이 요청에 포함된 Signature와 일치하면 요청자는 AWS 보안 액세스 키를 소유한 것으로 인증됩니다. 그런 다음 요청은 키가 발급되었던 개발자의 자격 증명과 권한으로 처리됩니다.

다음은 Authorization 요청 헤더의 생성을 보여 주는 구문의 예입니다. (이 예에서 \n은 줄 바꿈이라고 하는 유니코드 코드 포인트U+000A를 의미합니다).

Copy
Authorization = "AWS" + " " + AWSAccessKeyId + ":" + Signature; Signature = Base64( HMAC-SHA1( YourSecretAccessKeyID, UTF-8-Encoding-Of( StringToSign ) ) ); StringToSign = HTTP-Verb + "\n" + Content-MD5 + "\n" + Content-Type + "\n" + Date + "\n" + CanonicalizedAmzHeaders + CanonicalizedResource; CanonicalizedResource = [ "/" + Bucket ] + <HTTP-Request-URI, from the protocol name up to the query string> + [ subresource, if present. For example "?acl", "?location", "?logging", or "?torrent"]; CanonicalizedAmzHeaders = <described below>

HMAC-SHA1은 메시지 인증에 대한 RFC 2104 - 키-해싱으로 정의되는 알고리즘입니다. 알고리즘은 키와 메시지로 구성된 2바이트 문자열을 입력으로 사용합니다. Amazon S3 인증 요청의 경우, AWS 보안 액세스 키(YourSecretAccessKeyID)를 키로 사용하고 StringToSign의 UTF-8 인코딩을 메시지로 사용합니다. 또한 HMAC-SHA1의 출력은 다이제스트라고 하는 1바이트 문자열입니다. Signature 요청 파라미터는 Base64 인코딩 다이제스트로 구성됩니다.

서명에 대한 요청 정규화

시스템에서 인증된 요청을 받으면 계산된 이 요청 서명을, StringToSign의 요청에서 제공된 서명과 비교한다는 것을 기억하십시오. 이러한 이유로 인해 Amazon S3가 사용한 방법과 동일한 방법으로 서명을 계산해야 합니다. 서명 정규화를 위해 요청을 합의된 형식에 추가(put)하는 프로세스를 호출합니다.

CanonicalizedResource 요소 구성

CanonicalizedResource는 요청 대상인 Amazon S3 리소스를 나타냅니다. REST 요청의 경우 다음과 같이 작성합니다.

프로세스 시작

1

빈 문자열("")로 시작합니다.

2

요청이 HTTP 호스트 헤더(가상 호스팅 방식)를 사용하여 버킷을 지정할 경우, 버킷 이름 앞에 "/"를 붙입니다(예: "/bucketname"). 경로 방식 요청 및 버킷을 다루지 않는 요청에는 해당되지 않습니다. 가상 호스팅 방식 요청에 대한 자세한 내용은 버킷의 가상 호스팅을 참조하십시오.

가상 호스팅 방식 요청인 "https://johnsmith.s3.amazonaws.com/photos/puppy.jpg"에서 CanonicalizedResource는 "/johnsmith"입니다.

경로 방식 요청인 "https://s3.amazonaws.com/johnsmith/photos/puppy.jpg"에서 CanonicalizedResource는 ""입니다.

3

디코딩되지 않는 HTTP 요청 URI의 경로 부분을 쿼리 문자열 직전까지 추가합니다.

가상 호스팅 방식 요청인 "https://johnsmith.s3.amazonaws.com/photos/puppy.jpg"에서 CanonicalizedResource는 "/johnsmith/photos/puppy.jpg"입니다.

경로 방식 요청인 "https://s3.amazonaws.com/johnsmith/photos/puppy.jpg"에서 CanonicalizedResource는 "/johnsmith/photos/puppy.jpg"입니다. 이 시점에서 CanonicalizedResource는 가상 호스팅 방식과 경로 방식 요청에서 동일합니다.

GET Service와 같이 버킷을 다루지 않는 요청의 경우, "/"를 추가합니다.

4

요청이 ?versioning, ?location, ?acl, ?torrent, ?lifecycle 또는 ?versionid와 같은 하위 리소스를 다루는 경우, 하위 리소스와 하위 리소스의 값(있을 경우) 그리고 물음표를 추가합니다. 하위 리소스가 여러 개일 경우, 하위 리소스 이름에 따라 문자순으로 정렬되고 '&'로 구분됩니다(예: ?acl&versionId=value).

CanonicalizedResource 요소를 작성할 때 포함되어야 하는 하위 리소스는 acl, lifecycle, location, logging, notification, partNumber, policy, requestPayment, torrent, uploadId, uploads, versionId, versioning, versions, website입니다.

요청이 응답 헤더 값을 재정의하 쿼리 문자열 파라미터를 지정할 경우(객체 Get 참조), 쿼리 문자열 파라미터와 그 값을 추가합니다. 서명 시에는 이러한 값을 인코딩하지 않지만, 요청을 할 때에는 이러한 파라미터 값을 인코딩해야 합니다. GET 요청의 쿼리 문자열 파라미터에는 response-content-type, response-content-language, response-expires, response-cache-control, response-content-disposition, response-content-encoding이 포함됩니다.

다중 객체 삭제 요청에 대한 CanonicalizedResource를 생성할 경우에는 delete 쿼리 문자열 파라미터가 포함되어야 합니다.

HTTP 요청 URI에서 파생된 CanonicalizedResource의 요소는 URL 인코딩 메타 문자를 포함하여 HTTP 요청에 표시된 그대로 서명되어야 합니다.

CanonicalizedResource는 HTTP 요청-URI와는 다를 수 있습니다. 특히, 요청이 HTTP Host 헤더를 사용하여 버킷을 지정할 경우에는 HTTP 요청-URI에 버킷이 표시되지 않습니다. 하지만 CanonicalizedResource에는 계속 버킷이 포함됩니다. 쿼리 문자열 파라미터는 요청-URI에 표시될 수 있지만 CanonicalizedResource에는 포함되지 않습니다. 자세한 내용은 버킷의 가상 호스팅단원을 참조하십시오.

CanonicalizedAmzHeaders 요소 구성

StringToSign의 CanonicalizedAmzHeaders 부분을 작성하려면 'x-amz-'(대/소문자 구분 없는 비교 사용)로 시작하는 모든 HTTP 요청 헤더를 선택한 후 다음 프로세스를 사용합니다.

CanonicalizedAmzHeaders 프로세스

1 각 HTTP 헤더 이름을 소문자로 변환합니다. 예를 들어 'X-Amz-Date'는 'x-amz-date'가 됩니다.
2 헤더 컬렉션을 헤더 이름에 따라 문자순으로 정렬합니다.
3 이름이 같은 헤더 필드를 RFC 2616, 단원 4.2에 지정된 대로 값 사이 공백 없이 하나의 "헤더 이름:쉼표로 구분된 값 목록" 페어로 통합합니다. 예를 들어 두 개의 메타데이터 헤더인 'x-amz-meta-username: fred'와 'x-amz-meta-username: barney'는 하나의 'x-amz-meta-username: fred,barney' 헤더로 통합됩니다.
4 RFC 2616, 단원 4.2의 허용에 따라 여러 줄을 차지하는 긴 헤더는 폴딩 공백(줄 바꿈 포함)을 하나의 공백으로 바꿔서 펼칩니다(언폴딩).
5 헤더에서 콜론 앞뒤의 공백을 자릅니다. 예를 들어 'x-amz-meta-username: fred,barney'는 'x-amz-meta-username:fred,barney'가 됩니다.
6 마지막으로 줄 바꿈 문자(U+000A)를 결과 목록의 정규화된 각 헤더에 추가합니다. 이 목록의 모든 헤더를 하나의 문자열로 연결하여 CanonicalizedResource 요소를 작성합니다.

위치 및 이름 지정된 HTTP 헤더 StringToSign 요소

StringToSign의 처음 몇 개 요소(Content-Type, Date, Content-MD5)는 위치와 관련된 것입니다. StringToSign은 이러한 헤더 이름을 포함하지 않고 요청의 값만을 포함합니다. 반면에 'x-amz-' 요소에는 이름이 지정됩니다. 헤더 이름과 헤더 값은 모두 StringToSign에 표시됩니다.

StringToSign 정의에서 호출하는 위치 헤더가 요청에 없으면(예를 들어 Content-Type 또는 Content-MD5가 PUT 요청의 경우 선택 사항이고, GET 요청의 경우 필요 없을 경우), 해당 위치를 빈 문자열("")로 대체합니다.

타임스탬프 요구 사항

HTTP Date 헤더 또는 x-amz-date 대체 헤더를 사용하는 유효한 타임스탬프는 인증된 요청에 필수입니다. 또한 인증된 요청에 포함된 클라이언트 타임스탬프는 요청 수신 시 Amazon S3 시스템 시간이 15분 이내여야 합니다. 그렇지 않을 경우 RequestTimeTooSkewed 오류 코드와 함께 요청이 실패합니다. 이렇게 제한하는 목적은 악의적으로 가로챈 요청을 재실행할 수 있는 가능성을 제한하기 위한 것입니다. 도청에 대한 보안을 강화하려면 인증된 사용자에 대해 HTTPS 전송을 사용합니다.

참고

요청 날짜에 대한 검증 제약 조건은 쿼리 문자열 인증을 사용하지 않는 인증된 요청에만 적용됩니다. 자세한 내용은 쿼리 문자열 요청 인증 대체 방법단원을 참조하십시오.

일부 HTTP 클라이언트 라이브러리는 요청에 대한 Date 헤더 설정 가능 여부를 표시하지 않습니다. 정규화된 헤더에 'Date' 헤더 값을 포함하는 데 문제가 있을 경우, 대신 'x-amz-date' 헤더를 사용하여 요청에 대한 타임스탬프를 설정할 수 있습니다. x-amz-date 헤더의 값은 RFC 2616 형식(http://www.ietf.org/rfc/rfc2616.txt) 중 하나여야 합니다. x-amz-date 헤더가 요청에 있으면 시스템에서 요청 서명을 계산할 때 모든 Date 헤더를 무시합니다. 따라서 x-amz-date 헤더를 포함할 경우에는 StringToSign을 작성할 때 Date에 빈 문자열을 사용하십시오. 다음 단원의 예제를 참조하십시오.

인증 예제

이 단원의 예제에서는 다음 표의 (작동하지 않는) 자격 증명을 사용합니다.

매개 변수
AWSAccessKeyId AKIAIOSFODNN7EXAMPLE
AWSSecretAccessKey wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY

StringToSign 예제에서 형식은 크게 중요하지 않으며 \n은 일반적으로 줄 바꿈이라고 하는 유니코드 코드 포인트 U+000A를 의미합니다. 또한 이 예제는 "+0000"을 사용하여 표준 시간대를 지정합니다. 대신 "GMT"를 사용하여 표준 시간대를 지정할 수 있지만 예제에 나와 있는 서명이 달라집니다.

예 객체 GET

이 예제는 johnsmith 버킷에서 객체를 가져옵니다.

요청 StringToSign
Copy
GET /photos/puppy.jpg HTTP/1.1 Host: johnsmith.s3.amazonaws.com Date: Tue, 27 Mar 2007 19:36:42 +0000 Authorization: AWS AKIAIOSFODNN7EXAMPLE: bWq2s1WEIj+Ydj0vQ697zp+IXMU=
Copy
GET\n \n \n Tue, 27 Mar 2007 19:36:42 +0000\n /johnsmith/photos/puppy.jpg

CanonicalizedResource는 버킷 이름을 포함하지만 HTTP 요청-URI는 그렇지 않습니다. 버킷은 호스트 헤더가 지정합니다.

예 Object PUT

이 예제는 johnsmith 버킷으로 객체를 가져옵니다.

요청 StringToSign
Copy
PUT /photos/puppy.jpg HTTP/1.1 Content-Type: image/jpeg Content-Length: 94328 Host: johnsmith.s3.amazonaws.com Date: Tue, 27 Mar 2007 21:15:45 +0000 Authorization: AWS AKIAIOSFODNN7EXAMPLE: MyyxeRY7whkBe+bq8fHCL/2kKUg=
Copy
PUT\n \n image/jpeg\n Tue, 27 Mar 2007 21:15:45 +0000\n /johnsmith/photos/puppy.jpg

요청과 StringToSign의 Content-Type 헤더에 유의합니다. 또한 Content-MD5는 요청에 나타나지 않기 때문에 StringToSign에서 공백이어야 합니다.

예 목록

이 예제는 johnsmith 버킷의 콘텐츠를 나열합니다.

요청 StringToSign
Copy
GET /?prefix=photos&max-keys=50&marker=puppy HTTP/1.1 User-Agent: Mozilla/5.0 Host: johnsmith.s3.amazonaws.com Date: Tue, 27 Mar 2007 19:42:41 +0000 Authorization: AWS AKIAIOSFODNN7EXAMPLE: htDYFYduRNen8P9ZfE/s9SuKy0U=
Copy
GET\n \n \n Tue, 27 Mar 2007 19:42:41 +0000\n /johnsmith/

CanonicalizedResource 뒤에 슬래시가 오고, 쿼리 문자열 파라미터가 없다는 점에 유의합니다.

예 가져오기

이 예제는 'johnsmith' 버킷에 대한 액세스 제어 정책 하위 리소스를 가져옵니다.

요청 StringToSign
Copy
GET /?acl HTTP/1.1 Host: johnsmith.s3.amazonaws.com Date: Tue, 27 Mar 2007 19:44:46 +0000 Authorization: AWS AKIAIOSFODNN7EXAMPLE: c2WLPFtWHVgbEmeEG93a4cG37dM=
Copy
GET\n \n \n Tue, 27 Mar 2007 19:44:46 +0000\n /johnsmith/?acl

CanonicalizedResource에 하위 리소스 쿼리 문자열 파라미터가 어떻게 포함되는지를 살펴보십시오.

예 삭제

이 예제는 경로 방식 및 Date 대체 헤더를 사용하여 'johnsmith' 버킷에서 객체를 제거합니다.

요청 StringToSign
Copy
DELETE /johnsmith/photos/puppy.jpg HTTP/1.1 User-Agent: dotnet Host: s3.amazonaws.com Date: Tue, 27 Mar 2007 21:20:27 +0000 x-amz-date: Tue, 27 Mar 2007 21:20:26 +0000 Authorization: AWS AKIAIOSFODNN7EXAMPLE:lx3byBScXR6KzyMaifNkardMwNk=
Copy
DELETE\n \n \n Tue, 27 Mar 2007 21:20:26 +0000\n /johnsmith/photos/puppy.jpg

클라이언트 라이브러리로 인해 날짜를 설정할 수 없어서 'x-amz-date' 메서드를 대신 사용하여 어떻게 날짜를 지정했는지 살펴보십시오. 이 경우 x-amz-dateDate 헤더보다 우선 적용됩니다. 따라서 서명의 날짜 항목에 x-amz-date 헤더 값이 포함되어야 합니다.

예 업로드

이 예제는 메타데이터와 함께 CNAME 방식의 가상 호스팅 버킷에 객체를 업로드합니다.

요청 StringToSign
Copy
PUT /db-backup.dat.gz HTTP/1.1 User-Agent: curl/7.15.5 Host: static.johnsmith.net:8080 Date: Tue, 27 Mar 2007 21:06:08 +0000 x-amz-acl: public-read content-type: application/x-download Content-MD5: 4gJE4saaMU4BqNR0kLY+lw== X-Amz-Meta-ReviewedBy: joe@johnsmith.net X-Amz-Meta-ReviewedBy: jane@johnsmith.net X-Amz-Meta-FileChecksum: 0x02661779 X-Amz-Meta-ChecksumAlgorithm: crc32 Content-Disposition: attachment; filename=database.dat Content-Encoding: gzip Content-Length: 5913339 Authorization: AWS AKIAIOSFODNN7EXAMPLE: ilyl83RwaSoYIEdixDQcA4OnAnc=
Copy
PUT\n 4gJE4saaMU4BqNR0kLY+lw==\n application/x-download\n Tue, 27 Mar 2007 21:06:08 +0000\n x-amz-acl:public-read\n x-amz-meta-checksumalgorithm:crc32\n x-amz-meta-filechecksum:0x02661779\n x-amz-meta-reviewedby: joe@johnsmith.net,jane@johnsmith.net\n /static.johnsmith.net/db-backup.dat.gz

'x-amz-' 헤더가 어떻게 정렬되고, 공백이 잘렸으며, 소문자로 변환되었는지 살펴보십시오. 또한 이름이 같은 여러 헤더가 값을 구분하는 쉼표를 사용하여 어떻게 결합되었는지도 살펴보십시오.

Content-TypeContent-MD5 HTTP 엔터티 헤더만StringToSign에 표시되는 것에 유의합니다. 다른 Content-* 엔터티 헤더는 표시되지 않습니다.

즉, CanonicalizedResource에는 버킷 이름이 포함되지만, HTTP 요청-URI에는 포함되지 않습니다. 버킷은 호스트 헤더가 지정합니다.

예 내 버킷 모두 나열하기

요청 StringToSign
Copy
GET / HTTP/1.1 Host: s3.amazonaws.com Date: Wed, 28 Mar 2007 01:29:59 +0000 Authorization: AWS AKIAIOSFODNN7EXAMPLE:qGdzdERIC03wnaRNKh6OqZehG9s=
Copy
GET\n \n \n Wed, 28 Mar 2007 01:29:59 +0000\n /

예 유니코드 키

요청 StringToSign
Copy
GET /dictionary/fran%C3%A7ais/pr%c3%a9f%c3%a8re HTTP/1.1 Host: s3.amazonaws.com Date: Wed, 28 Mar 2007 01:49:49 +0000 Authorization: AWS AKIAIOSFODNN7EXAMPLE:DNEZGsoieTZ92F3bUfSPQcbGmlM=
Copy
GET\n \n \n Wed, 28 Mar 2007 01:49:49 +0000\n /dictionary/fran%C3%A7ais/pr%c3%a9f%c3%a8re

참고

요청-URI에서 파생된 StringToSign의 요소는 URL-인코딩 및 대문자를 포함하여 그대로 처리됩니다.

REST 요청 서명 문제

REST 요청 인증이 실패하면 시스템은 XML 오류 문서로 요청에 응답합니다. 이 오류 문서에 포함된 정보를 통해 개발자는 문제를 진단할 수 있습니다. 특히, SignatureDoesNotMatch 오류 문서의 StringToSign 요소는 시스템에서 사용하는 정확한 요청 정규화를 정확히 알려 줍니다.

일부 도구 키트는 PUT 과정에서 Content-Type 헤더와 같은 헤더 삽입을 자동으로 수행합니다. 대부분의 경우 삽입된 헤더의 값은 그대로 유지되므로 Ethereal 또는 tcpmon과 같은 도구를 사용하여 누락된 헤더를 발견할 수 있습니다.

쿼리 문자열 요청 인증 대체 방법

Authorization HTTP 헤더를 사용하는 대신 쿼리 문자열 파라미터로 필요한 정보를 전달하여 특정 유형의 요청을 인증할 수 있습니다. 이 방법은 요청을 프록시하지 않고 Amazon S3 비공개 데이터에 타사 브라우저가 액세스할 수 있도록 할 경우에 유용합니다. 방법은 "미리 서명된" 요청을 작성한 후 이를 최종 사용자의 브라우저가 검색할 수 있는 URL로 인코딩하는 것입니다. 또한 만료 시간을 지정하여 미리 서명된 요청을 제한할 수 있습니다.

참고

AWS SDK를 사용하여 미리 서명된 URL을 생성하는 예제는 다른 사용자와 객체 공유를 참조하십시오.

서명 생성

다음은 쿼리 문자열 인증 Amazon S3 REST 요청의 예제입니다.

Copy
GET /photos/puppy.jpg ?AWSAccessKeyId=AKIAIOSFODNN7EXAMPLE&Expires=1141889120&Signature=vjbyPxybdZaNmGa%2ByT272YEAiv4%3D HTTP/1.1 Host: johnsmith.s3.amazonaws.com Date: Mon, 26 Mar 2007 19:37:58 +0000

쿼리 문자열 요청 인증 메서드는 특별한 HTTP 헤더를 필요로 하지 않습니다. 대신에 필수 인증 요소는 쿼리 문자열 파라미터로 지정됩니다.

쿼리 문자열 파라미터 이름 예제 값 설명
AWSAccessKeyId AKIAIOSFODNN7EXAMPLE AWS 액세스 키 ID. 요청에 서명하는 데 사용되는 AWS 보안 액세스 키를 지정하고, 요청을 하는 개발자의 자격 증명을 간접적으로 지정합니다.
Expires 1141889120 서명이 만료되는 시간으로, epoch(1970년 1월 1일 00:00:00 UTC) 이후 경과 시간(초)으로 지정됩니다. 이 시간이 지나면(서버 기준) 요청이 거절됩니다.
Signature vjbyPxybdZaNmGa%2ByT272YEAiv4%3D URL 인코딩으로, StringToSign의 HMAC-SHA1의 Base64 인코딩입니다.

쿼리 문자열 요청 인증 메서드는 일반적인 메서드와 약간 다르며, Signature 요청 파라미터 및 StringToSign 요소의 형식도 다릅니다. 다음은 쿼리 문자열 인증 메서드를 보여 주는 구문의 예입니다.

Copy
Signature = URL-Encode( Base64( HMAC-SHA1( YourSecretAccessKeyID, UTF-8-Encoding-Of( StringToSign ) ) ) ); StringToSign = HTTP-VERB + "\n" + Content-MD5 + "\n" + Content-Type + "\n" + Expires + "\n" + CanonicalizedAmzHeaders + CanonicalizedResource;

YourSecretAccessKeyID는 Amazon 웹 서비스 개발자로 등록할 때 Amazon에서 할당한 AWS 보안 액세스 키 ID입니다. Signature가 쿼리 문자열에 배치될 수 있도록 URL 인코딩된 것에 유의하십시오. 또한 StringToSign에서 HTTP Date 위치 요소가 Expires로 교체되었음에 유의합니다. CanonicalizedAmzHeadersCanonicalizedResource는 동일합니다.

참고

쿼리 문자열 인증 메서드에서 서명할 문자열을 계산할 때 Date 또는 x-amz-date request 헤더를 사용하지 않습니다.

예 쿼리 문자열 요청 인증

요청 StringToSign
Copy
GET /photos/puppy.jpg?AWSAccessKeyId=AKIAIOSFODNN7EXAMPLE& Signature=NpgCjnDzrM%2BWFzoENXmpNDUsSn8%3D& Expires=1175139620 HTTP/1.1 Host: johnsmith.s3.amazonaws.com
Copy
GET\n \n \n 1175139620\n /johnsmith/photos/puppy.jpg

브라우저가 GET 요청을 할 때 Content-MD5 또는 Content-Type 헤더를 제공하지 않으며 어떠한 x-amz- 헤더도 설정하지 않으며 따라서 StringToSign의 부분은 공백으로 남는다고 가정합니다.

Base64 인코딩 사용

HMAC 요청 서명은 Base64 인코딩이어야 합니다. Base64 인코딩은 서명을 요청에 연결할 수 있는 간단한 ASCII 문자열로 변환할 수 있습니다. 더하기(+), 슬래시(/), 등호(=)와 같이 서명 문자열에 나타날 수 있는 문자는 URI에 사용할 경우 인코딩해야 합니다. 예를 들어 인증 코드에 더하기(+) 기호가 포함될 경우, 요청에서 %2B로 인코딩해야 합니다. 슬래시는 %2F, 등호는 %3D로 인코딩합니다.

Base64 방식의 인코딩은 Amazon S3 인증 예제를 참조하십시오.