Signieren und Authentifizieren von REST-Anfragen (AWS Signatur (Version 2)

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 AWS geheimen Zugriffsschlüssel, um den HMAC dieser Zeichenfolge zu berechnen. Informell wird dieser Vorgang als „Signieren der Anfrage“ bezeichnet, und die Ausgabe des HMAC-Algorithmus ist die Signatur, da sie die Sicherheitseigenschaften einer echten 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 Anfrage erhält, ruft es den AWS geheimen Zugriffsschlüssel ab, den Sie angeblich besitzen, und verwendet ihn auf die gleiche Weise, um eine Signatur für die empfangene Nachricht zu berechnen. Anschließend vergleicht es die berechnete Signatur mit der Signatur, die der Anforderer vorgezeigt hat. Wenn die beiden Signaturen übereinstimmen, kommt das System zu dem Schluss, dass der Anforderer Zugriff auf den AWS geheimen Zugriffsschlüssel haben muss, und handelt daher mit der Autorität des Prinzipals, an den 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 im AWS -Security-Token-Service API-Referenzhandbuch unter Action.

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

Entwickler erhalten bei der Registrierung eine AWS Zugriffsschlüssel-ID und einen AWS geheimen Zugriffsschlüssel. 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 der RFC 2104 HMAC-SHA1 der ausgewählten Elemente aus der Anfrage, weshalb der Signature Teil des Authorization-Headers von Anfrage zu Anfrage unterschiedlich ist. Wenn die vom System berechnete Anforderungssignatur mit der in der Anfrage Signature enthaltenen übereinstimmt, hat der Anforderer nachgewiesen, dass er im Besitz des AWS geheimen Zugangsschlüssels ist. 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 in RFC 2104 definierter Algorithmus Keyed-Hashing für die Nachrichtenauthentifizierung. Der Algorithmus nimmt zwei Byte-Zeichenfolgen als Eingabe entgegen, einen Schlüssel und eine Nachricht. Verwenden Sie für die Amazon S3-Anforderungsauthentifizierung Ihren AWS geheimen Zugriffsschlüssel (YourSecretAccessKey) als Schlüssel und die UTF-8 Kodierung von StringToSign als Nachricht. Die Ausgabe von HMAC-SHA1 ist ebenfalls eine Bytezeichenfolge, die als Digest bezeichnet wird. 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. Der Vorgang, bei dem eine Anfrage zur Unterzeichnung der Kanonisierung in einer vereinbarten Form gestellt wird.

CanonicalizedResource Konstruieren des Elements

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

Elemente von CanonicalizedResource , die aus dem HTTP stammen, Request-URI sollten wörtlich so signiert werden, wie sie in der HTTP-Anfrage vorkommen, einschließlich URL-Encoding Metazeichen.

Das CanonicalizedResource könnte anders sein als das HTTP Request-URI. Insbesondere, wenn Ihre Anfrage den Host HTTP-Header verwendet, um einen Bucket anzugeben, erscheint der Bucket nicht im HTTP Request-URI. Die CanonicalizedResource beinhaltet den Bucket jedoch weiterhin. Abfragezeichenfolgenparameter können auch in der vorkommen Request-URI , sind aber nicht in enthaltenCanonicalizedResource. Weitere Informationen finden Sie unter Virtuelles Hosten von Buckets.

Das Element konstruieren CanonicalizedAmzHeaders

Um den CanonicalizedAmzHeaders Teil von zu konstruierenStringToSign, wählen Sie alle HTTP-Anforderungsheader aus, die mit 'x-amz-' beginnen (bei einem Vergleich ohne Berücksichtigung der Groß- und Kleinschreibung), und gehen Sie wie folgt vor.

Positionelle und benannte HTTP-Header-Elemente StringToSign

Die ersten Header-Elemente von StringToSign (Content-Type, Date und Content-MD5) sind positioneller Natur. StringToSignenthält nicht die Namen dieser Header, sondern nur ihre Werte aus der Anfrage. 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 in einem der von RFC 2616 vorgegebenen Formate vorliegen (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 der den Bucket-Namen CanonicalizedResource enthält, HTTP jedoch Request-URI 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 Anfrage und in der StringToSign. Beachten Sie auch, dass das in der leer gelassen Content-MD5 wird StringToSign, da es in der Anfrage 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/

Beachten Sie den abschließenden Schrägstrich bei CanonicalizedResource und das Fehlen von Abfragezeichenfolgenparametern.

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, dass der Parameter für die Subresource-Abfragezeichenfolge in der enthalten ist. CanonicalizedResource

Delete

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 die alternative Methode „x-amz-date“ zur Angabe des Datums (weil unsere Client-Bibliothek uns beispielsweise daran gehindert hat, das Datum festzulegen). 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 auch hier, dass der den Bucket-Namen CanonicalizedResource enthält, HTTP Request-URI jedoch 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 zur Authentifizierung von Anfragen finden Sie unter Authentifizieren von Anfragen: Verwenden von Abfrageparametern (AWS Signature Version 4) in der Amazon Simple Storage Service API-Referenz. Beispiele für die Verwendung der AWS SDKs zum Generieren vorsignierter URLs finden Sie unter Objekte mit vorsignierten URLs teilen.

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;    

YourSecretAccessKeyist die AWS geheime Zugriffsschlüssel-ID, die Amazon Ihnen zuweist, wenn Sie sich als Amazon Web Service-Entwickler registrieren. Beachten Sie URL-Encoded , wie Signature das für die Platzierung in der Abfragezeichenfolge 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

In diesem Beispiel wird davon ausgegangen, dass ein Browser, wenn er die GET-Anfrage stellt, weder einen Content-MD5 oder Content-Type -Header bereitstellt, noch irgendwelche x-amz-Header setzt, sodass diese Teile von leer StringToSign bleiben.

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.