Signieren und Authentifizieren von REST-Anforderungen

Die Authentifizierung ist der Prozess, Ihre Identität gegenüber dem System nachzuweisen. Die Identität ist ein wichtiger Faktor in den Zugriffssteuerungsentscheidungen von Amazon S3. Anforderungen werden zum Teil basierend auf der Identität des Auftraggebers zugelassen oder abgewiesen. Das Recht, Buckets zu erstellen, ist beispielsweise für registrierte Entwickler reserviert (standardmäßig), und das Recht, Objekte in einem Bucket zu erstellen, ist für den Eigentümer des betreffenden Buckets reserviert. Als Entwickler machen Sie Anforderungen, für die diese Berechtigungen gelten müssen, deshalb müssen Sie Ihre Identität gegenüber dem System belegen, indem Sie Ihre Anforderungen authentifizieren. In diesem Abschnitt erfahren Sie mehr darüber.

Die Amazon-S3-REST-API verwendet ein allgemeines HTTP-Schema basierend auf einem verschlüsselten HMAC (Hash Message Authentication Code) für die Authentifizierung. Um eine Anforderung zu authentifizieren, verknüpfen Sie zuerst ausgewählte Elemente der Anforderung, um eine Zeichenfolge zu erstellen. Anschließend verwenden Sie Ihren geheimen AWS-Zugriffsschlüssel, um den HMAC für diese Zeichenfolge zu berechnen. Informell bezeichnen wir diesen Prozess als „Signieren der Anforderung“. Wir bezeichnen die Ausgabe des HMAC-Algorithmus als die Signatur, weil sie die Sicherheitseigenschaften einer realen Signatur simuliert. Schließlich fügen Sie diese Signatur als Parameter der Anforderung hinzu. Dazu verwenden Sie die in diesem Abschnitt beschriebene Syntax.

Wenn das System eine authentifizierte Anforderung erhält, lädt es den geheimen AWS-Zugriffsschlüssel, den Sie behaupten zu haben, und verwendet ihn genau so, um aus der empfangenen Nachricht eine Signatur zu berechnen. Anschließend vergleicht es die berechnete Signatur mit der Signatur, die der Anforderer vorgezeigt hat. Stimmen die beiden Signaturen überein, schließt das System daraus, dass der Anforderer Zugriff auf den geheimen AWS-Zugriffsschlüssel hat, und damit mit der Genehmigung des Prinzipals handelt, dem der Schlüssel ausgestellt wurde. Stimmen die beiden Signaturen nicht überein, wird die Anforderung verworfen und das System antwortet mit einer Fehlermeldung.

GET /photos/puppy.jpg HTTP/1.1
Host: awsexamplebucket1.us-west-1.s3.amazonaws.com
Date: Tue, 27 Mar 2007 19:36:42 +0000

Authorization: AWS AKIAIOSFODNN7EXAMPLE:
qgk2+6Sv9/oM7G3qLEjTH1a1l1g=

Verwenden von temporären Sicherheitsanmeldeinformationen

Wenn Sie Ihre Anfrage unter Verwendung temporärer Sicherheitsanmeldeinformationen signieren (siehe Senden von Anforderungen), müssen Sie das entsprechende Sicherheitstoken in Ihre Anfrage aufnehmen, indem Sie den x-amz-security-token-Header hinzufügen.

Wenn Sie unter Verwendung der AWS Security Token Service API temporäre Sicherheitsanmeldeinformationen erhalten haben, beinhaltet die Antwort temporäre Sicherheitsanmeldeinformationen und ein Sitzungstoken. Sie geben den Wert des Sitzungstokens im x-amz-security-token-Header an, wenn Sie Anfragen an Amazon S3 senden. Informationen zur von IAM bereitgestellten AWS Security Token Service-API finden Sie unter Aktions (Aktionen) im AWS Security Token Service-API-Referenzhandbuch.

Der Authentifizierungsheader

Die Amazon-S3-REST-API verwendet den standardmäßigen HTTP-Authorization-Header, um Authentifizierungs-Informationen weiterzugeben. (Der Name des Standardheaders ist unglücklich gewählt, weil er eine Authentifizierung weitergibt, keine Autorisierung.) Unter dem Amazon-S3-Authentifizierungsschema hat der Autorisierungsheader die folgende Form:

Authorization: AWS AWSAccessKeyId:Signature

Entwicklern wird eine AWS-Zugriffsschlüssel-ID und ein geheimer AWS-Zugriffsschlüssel ausgestellt, wenn sie sich anmelden. Für die Anforderungs-Authentifizierung identifiziert das AWSAccessKeyId-Element die Zugriffsschlüssel-ID, die für die Berechnung der Signatur verwendet wurde, und indirekt für den Entwickler steht, der die Anforderung gestellt hat.

Das Signature-Element ist das RFC 2104 HMAC-SHA1 ausgewählter Elemente aus der Anforderung, der Signature-Teil des Authorization-Headers unterscheidet sich deshalb zwischen verschiedenen Anforderungen. Wenn die vom System berechnete Anforderungssignatur mit der in der Anforderung enthaltenen Signature übereinstimmt, hat der Auftraggeber belegt, dass er den geheimen AWS-Zugriffsschlüssel besitzt. die Anforderung wird unter der Identität verarbeitet, und mit der Genehmigung des Entwicklers, dem der Schlüssel ausgestellt wurde.

Die folgende Pseudogrammatik verdeutlicht den Aufbau des Authorization-Anforderungs-Headers. (In dem Beispiel steht \n für den Unicode-Code U+000A, häufig auch als Newline bezeichnet.)

Authorization = "AWS" + " " + AWSAccessKeyId + ":" + Signature;

Signature = Base64( HMAC-SHA1( UTF-8-Encoding-Of(YourSecretAccessKey), 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", or "?logging"];

CanonicalizedAmzHeaders = <described below>

HMAC-SHA1 ist ein von RFC 2104 - Keyed-Hashing for Message Authentication definierter Algorithmus. Der Algorithmus nimmt zwei Byte-Zeichenfolgen als Eingabe entgegen, einen Schlüssel und eine Nachricht. Für die Amazon-S3-Anfrageauthentifizierung verwenden Sie Ihren geheimen AWS-Zugriffsschlüssel (YourSecretAccessKey) als Schlüssel und die UTF-8-Codierung des StringToSign als die Meldung. Die Ausgabe von HMAC-SHA1 ist ebenfalls eine Byte-Zeichenfolge, der sogenannte Digest. Der Signature-Anforderungsparameter wird durch eine Base64-Codierung dieses Digest erstellt.

Anfordern einer Kanonisierung für die Signatur

Wenn das System eine authentifizierte Anforderung erhält, vergleicht es die berechnete Anforderungssignatur mit der in der Anforderung im breitgestellten Signatur, wie bereits beschriebe StringToSign. Aus diesem Grund müssen Sie die Signatur nach derselben Methode berechnen, die auch Amazon S3 verwendet. Wir bezeichnen diesen Prozess, bei dem eine Anforderung in die für die Signatur vereinbarte Form gebracht wird, als Kanonisierung.

Konstruieren des - CanonicalizedResource Elements

CanonicalizedResource stellt die für die Anfrage relevante Amazon-S3-Ressource dar. Für eine REST-Anforderung erstellen Sie sie wie folgt:

Elemente der CanonicalizedResource , die aus der HTTP Request-URI stammen, sollten so signiert werden, wie sie in der HTTP-Anforderung erscheinen, einschließlich URL-Kodierungsmetazeichen.

Möglicherweise unterschiedet sich die CanonicalizedResource von der HTTP Anforderungs-URI. Wenn Ihre Anforderung den HTTP-Header Host verwendet, um einen Bucket anzugeben, erscheint der Bucket nicht in der HTTP Anforderungs-URI. Die CanonicalizedResource beinhaltet den Bucket jedoch weiterhin. Abfrage-Zeichenfolgenparameter können auch in der Anforderungs-URI erscheinen, sind aber nicht in der enthalte CanonicalizedResource. Weitere Informationen finden Sie unter Virtuelles Hosting bei Buckets.

Konstruieren des - CanonicalizedAmzHeaders Elements

Um den CanonicalizedAmzHeaders Teil von zu erstellenStringToSign, wählen Sie alle HTTP-Anforderungsheader aus, die mit „x-amz-“ beginnen (unter Verwendung eines Vergleichs ohne Berücksichtigung der Groß- und Kleinschreibung), und gehen Sie wie folgt vor.

Positionale und benannte HTTP-Header- StringToSign Elemente

Die ersten Header-Elemente von StringToSign (Content-Type, Date und Content-MD5) sind von ihrer Art her positionsbezogen. StringToSign fügt nicht die Namen dieser Header, sondern nur ihre Werte aus der Anforderung ein. Im Gegensatz dazu sind die 'x-amz-'-Elemente benannt. Sowohl die Header-Namen als auch die Header-Werte erscheinen in StringToSign.

Wenn ein positionaler Header, der in der Definition von StringToSign vorgegeben ist, in Ihrer Anforderung nicht vorhanden ist (z. B. sind Content-Type oder Content-MD5 optionale für PUT-Anforderungen und sinnlos für GET-Anforderungen), setzen Sie in dieser Position die leere Zeichenfolge ("") ein.

Zeitstempel-Anforderung

Ein gültiger Zeitstempel (unter Verwendung des HTTP-Headers Date oder einer x-amz-date-Alternative) ist zwingend erforderlich für authentifizierte Anforderungen. Darüber hinaus muss der Client-Zeitstempel in einer authentifizierten Anfrage innerhalb eines Zeitraums von 15 Minuten zur Amazon-S3-Systemzeit liegen, wenn die Anfrage empfangen wird. Wenn dies nicht der Fall ist, schlägt die Anforderung mit RequestTimeTooSkewed-Fehlercode fehl. Diese Einschränkungen sollen verhindern, dass abgefangene Anforderungen böswillig wiederholt werden. Für einen strengeren Schutz gegen ein Abhören transportieren Sie authentifizierte Anforderung mit HTTPS.

Einige HTTP-Client-Bibliotheken unterstützen die Möglichkeit nicht, den Date-Header für eine Anforderung einzurichten. Wenn Sie Probleme damit haben, den Wert des 'Date'-Headers in kanonisierte Header aufzunehmen, können Sie den Zeitstempel für die Anforderung stattdessen auch mit einem 'x-amz-date'-Header einrichten. Der Wert des x-amz-date-Headers muss eines der RFC 2616-Formate haben (http://www.ietf.org/rfc/rfc2616.txt). Wenn in einer Anforderung ein x-amz-date-Header vorhanden ist, ignoriert das System bei der Berechnung der Anforderungssignatur jeden Date-Header. Wenn Sie also den x-amz-date-Header aufnehmen, verwenden Sie die leere Zeichenfolge für Date, wenn Sie den StringToSign erstellen. Ein Beispiel finden Sie im nächsten Abschnitt.

Authentifizierungsbeispiele

Die Beispiele in diesem Abschnitt verwenden die (nicht funktionierenden) Anmeldeinformationen aus der folgenden Tabelle.

In den StringToSigns des Beispiels ist die Formatierung nicht relevant, und \n steht für den Unicode-Punkt U+000A, allgemein als Neue-Zeile-Zeichen bezeichnet. Außerdem verwenden die Beispiele "+0000", um die Zeitzone anzugeben. Sie können die Zeitzone stattdessen mit "GMT" angeben, aber in den Beispielen werden andere Signaturen verwendet.

Object GET

In diesem Beispiel wird ein Objekt aus dem Bucket „awsexamplebucket1“ abgerufen.

GET /photos/puppy.jpg HTTP/1.1
Host: awsexamplebucket1.us-west-1.s3.amazonaws.com
Date: Tue, 27 Mar 2007 19:36:42 +0000

Authorization: AWS AKIAIOSFODNN7EXAMPLE:
qgk2+6Sv9/oM7G3qLEjTH1a1l1g=

GET\n
\n
\n
Tue, 27 Mar 2007 19:36:42 +0000\n
/awsexamplebucket1/photos/puppy.jpg

Beachten Sie, dass die den Bucket-Namen CanonicalizedResource enthält, die HTTP Request-URI jedoch nicht. (Der Bucket wird vom Host-Header spezifiziert.)

import base64
import hmac
from hashlib import sha1

access_key = 'AKIAIOSFODNN7EXAMPLE'.encode("UTF-8")
secret_key = 'wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY'.encode("UTF-8")

string_to_sign = 'GET\n\n\nTue, 27 Mar 2007 19:36:42 +0000\n/awsexamplebucket1/photos/puppy.jpg'.encode("UTF-8")
signature = base64.b64encode(
                                hmac.new(
                                         secret_key, string_to_sign, sha1
                                         ).digest()
                                ).strip()


print(f"AWS {access_key.decode()}:{signature.decode()}")

Object PUT

In diesem Beispiel wird ein Objekt in den Bucket „awsexamplebucket1“ eingefügt.

PUT /photos/puppy.jpg HTTP/1.1
Content-Type: image/jpeg
Content-Length: 94328
Host: awsexamplebucket1.s3.us-west-1.amazonaws.com
Date: Tue, 27 Mar 2007 21:15:45 +0000

Authorization: AWS AKIAIOSFODNN7EXAMPLE:
iqRzw+ileNPu1fhspnRs8nOjjIA=

PUT\n
\n
image/jpeg\n
Tue, 27 Mar 2007 21:15:45 +0000\n
/awsexamplebucket1/photos/puppy.jpg

Notieren Sie sich den Content-Type-Header in der Anforderung und in der StringToSign. Beachten Sie auch, dass Content-MD5 in der leer gelassen wird StringToSign, da es in der Anforderung nicht vorhanden ist.

Auflisten

In diesem Beispiel wird der Inhalt des Buckets „awsexamplebucket1“ aufgelistet.

GET /?prefix=photos&max-keys=50&marker=puppy HTTP/1.1
User-Agent: Mozilla/5.0
Host: awsexamplebucket1.s3.us-west-1.amazonaws.com
Date: Tue, 27 Mar 2007 19:42:41 +0000

Authorization: AWS AKIAIOSFODNN7EXAMPLE:
m0WP8eCtspQl5Ahe6L1SozdX9YA=

GET\n
\n
\n
Tue, 27 Mar 2007 19:42:41 +0000\n
/awsexamplebucket1/

Notieren Sie sich den abschließenden Schrägstrich in der CanonicalizedResource und das Fehlen von Abfragezeichenfolgeparametern.

Fetch

In diesem Beispiel wird die Zugriffskontrollrichtlinien-Subressource für den Bucket „awsexamplebucket1“ abgerufen.

GET /?acl HTTP/1.1
Host: awsexamplebucket1.s3.us-west-1.amazonaws.com
Date: Tue, 27 Mar 2007 19:44:46 +0000

Authorization: AWS AKIAIOSFODNN7EXAMPLE:
82ZHiFIjc+WbcwFKGUVEQspPn+0=

GET\n
\n
\n
Tue, 27 Mar 2007 19:44:46 +0000\n
/awsexamplebucket1/?acl

Beachten Sie, wie der Subressourcen-Abfragezeichenfolgeparameter in der enthalten ist CanonicalizedResource.

Löschen

In diesem Beispiel wird ein Objekt über die path-style- und Date-Alternative aus dem Bucket „awsexamplebucket1“ entfernt.

DELETE /awsexamplebucket1/photos/puppy.jpg HTTP/1.1
User-Agent: dotnet
Host: s3.us-west-1.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:XbyTlbQdu9Xw5o8P4iMwPktxQd8=

DELETE\n
\n
\n
Tue, 27 Mar 2007 21:20:26 +0000\n
/awsexamplebucket1/photos/puppy.jpg

Beachten Sie, wie wir die alternative Methode „x-amz-date“ zur Angabe des Datums verwendet haben (weil unsere Client-Bibliothek verhindert hat, dass wir das Datum festlegen konnten, z. B. ). In diesem Fall hat x-amz-date Vorrang vor dem Date-Header. Aus diesem Grund muss der Datumseintrag in der Signatur den Wert des x-amz-date-Headers enthalten.

Hochladen

Dieses Beispiel lädt ein Objekt in einen virtuell gehosteten Bucket mit CNAME-Stil mit Metadaten.

PUT /db-backup.dat.gz HTTP/1.1
User-Agent: curl/7.15.5
Host: static.example.com: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@example.com
X-Amz-Meta-ReviewedBy: jane@example.com
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:
jtBQa0Aq+DkULFI8qrpwIjGEx0E=

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@example.com,jane@example.com\n
/static.example.com/db-backup.dat.gz

Beachten Sie, wie die „x-amz-“-Header sortiert, von Leerzeichen befreit und in Kleinbuchstaben umgewandelt wurden. Beachten Sie außerdem, dass mehrere Header mit demselben Namen unter Verwendung von Kommas zum Trennen der Werte verknüpft wurden.

Beachten Sie, wie nur die HTTP-Header Content-Type und Content-MD5 in StringToSign erscheinen. Die anderen Content-*-Header erscheinen nicht.

Beachten Sie ebenfalls, dassCanonicalizedResource den Bucket-Namen beinhaltet, die HTTP Anforderungs-URI dagegen nicht. (Der Bucket wird vom Host-Header spezifiziert.)

Auflisten aller meiner Buckets

GET / HTTP/1.1
Host: s3.us-west-1.amazonaws.com
Date: Wed, 28 Mar 2007 01:29:59 +0000

Authorization: AWS AKIAIOSFODNN7EXAMPLE:qGdzdERIC03wnaRNKh6OqZehG9s=

GET\n
\n
\n
Wed, 28 Mar 2007 01:29:59 +0000\n
/

Unicode-Schlüssel

GET /dictionary/fran%C3%A7ais/pr%c3%a9f%c3%a8re HTTP/1.1
Host: s3.us-west-1.amazonaws.com
Date: Wed, 28 Mar 2007 01:49:49 +0000
Authorization: AWS AKIAIOSFODNN7EXAMPLE:DNEZGsoieTZ92F3bUfSPQcbGmlM=

GET\n
\n
\n
Wed, 28 Mar 2007 01:49:49 +0000\n
/dictionary/fran%C3%A7ais/pr%c3%a9f%c3%a8re

Probleme mit dem Signieren von REST-Anforderungen

Wenn die Authentifizierung einer REST-Anforderung fehlschlägt, reagiert das System mit einem XML-Fehlerdokument auf die Anforderung. Die in diesem Fehlerdokument enthaltene Information soll Entwicklern helfen, das Problem zu diagnostizieren. Insbesondere erkennen Sie an dem StringToSign-Element des SignatureDoesNotMatch-Fehlerdokuments genau, welche Anforderungs-Kanonisierung das System verwendet.

Einige Toolkits fügen stillschweigend Header ein, die Sie zuvor nicht kennen, wie beispielsweise den Header Content-Type bei einem PUT. In den meisten dieser Fälle bleibt der Wert des eingefügten Headers konstant, sodass Sie fehlende Header unter Verwendung von Tools wie Ethereal oder tcpmon erkennen können.

Alternative zur Authentifizierung der Abfragezeichenfolge

Einige Anforderungstypen können Sie authentifizieren, indem Sie die angeforderten Informationen als Abfragezeichenfolgenparameter übergeben, statt den HTTP-Header Authorization zu verwenden. Dies ist praktisch, um direkten Zugriff durch einen Browser von Dritten auf Ihre privaten Amazon-S3-Daten zu ermöglichen, ohne dass die Anfrage über einen Proxy gesendet wird. Die Idee besteht in der Konstruierung einer „vorsignierten“ Anforderung und ihrer Codierung als einer URL, die vom Browser eines Endbenutzers geladen werden kann. Darüber hinaus können Sie eine vorsignierte Anforderung durch die Angabe einer Ablaufzeit begrenzen.

Weitere Informationen zur Verwendung von Abfrageparametern zum Authentifizieren von Anforderungn finden Sie unter Authentifizieren von Anforderungn: Verwenden von Abfrageparametern (AWS Signature Version 4) in der Amazon Simple Storage Service API-Referenz. Beispiele für die Verwendung von AWS SDKs zum Generieren vorsignierter URLs finden Sie unter Gemeinsame Nutzung von Objekten mit vorsignierten URLs.

Erstellen einer Signatur

Das folgende Beispiel zeigt eine mit Abfragezeichenfolge authentifizierte Amazon-S3-REST-Anfrage.

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

Die Authentifizierungsmethode für die Abfragezeichenkette benötigt keine spezifischen HTTP-Header. Stattdessen werden die erforderlichen Authentifizierungselemente als Abfragezeichenfolgenparameter angegeben:

Die Methode zur Authentifizierung der Abfragezeichenfolge unterscheidet sich leicht von der üblichen Methode, aber nur im Format des Signature-Anforderungsparameters und des StringToSign-Elements. Die folgende Pseudogrammatik verdeutlicht die Authentifizierungsmethode für die Abfragezeichenfolge.

Signature = URL-Encode( Base64( HMAC-SHA1( YourSecretAccessKey, UTF-8-Encoding-Of( StringToSign ) ) ) );

StringToSign = HTTP-VERB + "\n" +
    Content-MD5 + "\n" +
    Content-Type + "\n" +
    Expires + "\n" +
    CanonicalizedAmzHeaders +
    CanonicalizedResource;    

YourSecretAccessKey ist die ID des geheimen AWS-Zugriffsschlüssels, die Ihnen Amazon zuordnet, wenn Sie sich als Amazon-Web-Services-Entwickler anmelden. Beachten Sie, wie die Signature URL-codiert wird, damit sie für die Platzierung im Abfragestring geeignet ist. Beachten Sie auch, dass in StringToSign das HTTP-Positionselement Date durch Expires ersetzt wurde. CanonicalizedAmzHeaders und CanonicalizedResource sind gleich.

Authentifizierung von Abfragezeichenfolgen-Anforderungen

GET /photos/puppy.jpg?AWSAccessKeyId=AKIAIOSFODNN7EXAMPLE&
    Signature=NpgCjnDzrM%2BWFzoENXmpNDUsSn8%3D&
    Expires=1175139620 HTTP/1.1

Host: awsexamplebucket1.s3.us-west-1.amazonaws.com

GET\n
\n
\n
1175139620\n

/awsexamplebucket1/photos/puppy.jpg

Wir gehen davon aus, dass ein Browser bei einer GET-Anforderung keinen Content-MD5- oder Content-Type-Header bereitstellt, und auch keine x-amz--Header einrichten, diese Teile von StringToSign bleiben deshalb leer.

Verwendung der Base64-Codierung

Signaturen von HMAC-Anforderungen müssen mit Base64 codiert werden. Die Base64-Codierung wandelt die Signatur in einen einfachen ASCII-String um, der der Anforderung hinzugefügt werden kann. Zeichen, die in der Signatur erscheinen können, wie beispielsweise Plus (+), Schrägstrich (/) oder Gleichheitszeichen (=), müssen wie in einer URI codiert werden. Enthält beispielsweise der Authentifizierungscode ein Plussymbol (+), codieren Sie es in der Anforderung als &2B. Einen Schrägstrich codieren Sie als &2F, ein Gleichheitszeichen als %3D.

Beispiele für die Base64-Codierung finden Sie in Amazon S3 Authentifizierungsbeispiele.