Otorisasi dengan Kunci Bersama

Artikel
07/11/2023

Setiap permintaan yang dibuat terhadap layanan penyimpanan harus diotorisasi, kecuali permintaannya adalah untuk sumber daya blob atau kontainer yang telah tersedia untuk akses publik atau ditandatangani. Salah satu opsi untuk mengotorisasi permintaan adalah dengan menggunakan Kunci Bersama, yang dijelaskan dalam artikel ini.

Tip

Azure Storage menyediakan integrasi dengan Microsoft Entra ID untuk otorisasi permintaan berbasis identitas ke layanan Blob, File, Antrean, dan Tabel. Dengan Microsoft Entra ID, Anda dapat menggunakan kontrol akses berbasis peran (RBAC) untuk memberikan akses ke sumber daya blob, file, antrean, dan tabel kepada pengguna, grup, atau aplikasi. Microsoft Entra ID dapat digunakan untuk mengotorisasi akses ke sumber daya penyimpanan tanpa menyimpan kunci akses akun di aplikasi Anda, seperti yang Anda lakukan dengan Kunci Bersama. Untuk informasi selengkapnya, lihat Mengotorisasi dengan Microsoft Entra ID.

Layanan Blob, Antrean, Tabel, dan File mendukung skema otorisasi Kunci Bersama berikut untuk versi 2009-09-19 dan yang lebih baru (untuk layanan Blob, Antrean, dan Tabel) dan versi 2014-02-14 dan yang lebih baru (untuk layanan File):

Kunci Bersama untuk Blob, Antrean, dan Layanan File. Gunakan skema otorisasi Kunci Bersama untuk membuat permintaan terhadap layanan Blob, Antrean, dan File. Otorisasi Kunci Bersama dalam versi 2009-09-19 dan yang lebih baru mendukung string tanda tangan tambahan untuk keamanan yang ditingkatkan dan mengharuskan Anda memperbarui layanan Anda untuk mengotorisasi menggunakan tanda tangan tambahan ini.
Kunci Bersama untuk Layanan Tabel. Gunakan skema otorisasi Kunci Bersama untuk membuat permintaan terhadap layanan Table menggunakan REST API. Otorisasi Kunci Bersama untuk layanan Table dalam versi 2009-09-19 dan yang lebih baru menggunakan string tanda tangan yang sama seperti pada versi layanan Tabel sebelumnya.
Shared Key Lite. Gunakan skema otorisasi Shared Key Lite untuk membuat permintaan terhadap layanan Blob, Queue, Table, dan File.

Untuk layanan Blob dan Antrean versi 2009-09-19 dan yang lebih baru, otorisasi Shared Key Lite mendukung penggunaan string tanda tangan yang identik dengan apa yang didukung terhadap Kunci Bersama di versi layanan Blob dan Antrean sebelumnya. Oleh karena itu, Anda dapat menggunakan Shared Key Lite untuk membuat permintaan terhadap layanan Blob dan Antrean tanpa memperbarui string tanda tangan Anda.

Permintaan yang diotorisasi memerlukan dua header: Date header atau x-ms-date dan Authorization header . Bagian berikut menjelaskan cara membuat header ini.

Penting

Azure Storage mendukung HTTP dan HTTPS, tetapi menggunakan HTTPS sangat disarankan.

Catatan

Kontainer atau blob dapat disediakan untuk akses publik dengan mengatur izin kontainer. Untuk informasi selengkapnya, lihat Mengelola Akses ke Sumber Daya Azure Storage. Kontainer, blob, antrean, atau tabel dapat disediakan untuk akses yang ditandatangani melalui tanda tangan akses bersama; tanda tangan akses bersama diotorisasi melalui mekanisme yang berbeda. Lihat Mendelegasikan akses dengan tanda tangan akses bersama untuk detail selengkapnya.

Menentukan header Tanggal

Semua permintaan yang diotorisasi harus menyertakan tanda waktu Waktu Universal Terkoordinasi (UTC) untuk permintaan tersebut. Anda dapat menentukan tanda waktu baik di x-ms-date header, atau di header HTTP/HTTPS Date standar. Jika kedua header ditentukan pada permintaan, nilai x-ms-date digunakan sebagai waktu pembuatan permintaan.

Layanan penyimpanan memastikan bahwa permintaan tidak lebih dari 15 menit pada saat mencapai layanan. Ini melindungi dari serangan keamanan tertentu, termasuk serangan pemutaran ulang. Ketika pemeriksaan ini gagal, server mengembalikan kode respons 403 (Terlarang).

Catatan

Header x-ms-date disediakan karena beberapa pustaka klien HTTP dan proksi secara otomatis mengatur Date header, dan tidak memberi pengembang kesempatan untuk membaca nilainya untuk menyertakannya dalam permintaan yang diotorisasi. Jika Anda mengatur x-ms-date, buat tanda tangan dengan nilai kosong untuk Date header .

Menentukan header Otorisasi

Permintaan yang diotorisasi harus menyertakan Authorization header . Jika header ini tidak disertakan, permintaan bersifat anonim dan hanya berhasil terhadap kontainer atau blob yang ditandai untuk akses publik, atau terhadap kontainer, blob, antrean, atau tabel yang tanda tangan akses bersamanya telah disediakan untuk akses yang didelegasikan.

Untuk mengotorisasi permintaan, Anda harus menandatangani permintaan dengan kunci untuk akun yang membuat permintaan dan meneruskan tanda tangan tersebut sebagai bagian dari permintaan.

Format untuk Authorization header adalah sebagai berikut:

Authorization="[SharedKey|SharedKeyLite] <AccountName>:<Signature>"

di mana SharedKey atau SharedKeyLite adalah nama skema otorisasi, AccountName adalah nama akun yang meminta sumber daya, dan Signature merupakan Kode Autentikasi Pesan berbasis Hash (HMAC) yang dibangun dari permintaan dan dihitung dengan menggunakan algoritma SHA256, lalu dikodekan dengan menggunakan pengodean Base64.

Catatan

Dimungkinkan untuk meminta sumber daya yang berada di bawah akun yang berbeda, jika sumber daya tersebut dapat diakses publik.

Bagian berikut menjelaskan cara membuat Authorization header.

Membuat string tanda tangan

Cara Anda membuat string tanda tangan tergantung pada layanan dan versi mana yang Anda otorisasi dan skema otorisasi mana yang Anda gunakan. Saat membuat string tanda tangan, ingatlah hal berikut:

Bagian KATA KERJA dari string adalah kata kerja HTTP, seperti GET atau PUT, dan harus huruf besar.
Untuk otorisasi Kunci Bersama untuk layanan Blob, Antrean, dan File, setiap header yang disertakan dalam string tanda tangan hanya dapat muncul sekali. Jika ada header yang diduplikasi, layanan mengembalikan kode status 400 (Permintaan Buruk).
Nilai semua header HTTP standar harus disertakan dalam string dalam urutan yang diperlihatkan dalam format tanda tangan, tanpa nama header. Header ini dapat kosong jika tidak ditentukan sebagai bagian dari permintaan; dalam hal ini, hanya karakter baris baru yang diperlukan.
x-ms-date Jika header ditentukan, Anda dapat mengabaikan Date header, terlepas dari apakah header ditentukan pada permintaan, dan cukup tentukan baris kosong untuk Date bagian string tanda tangan. Dalam hal ini, ikuti instruksi di bagian Membuat string header kanonis untuk menambahkan x-ms-date header.

Dapat diterima untuk menentukan dan x-ms-dateDate; dalam hal ini, layanan menggunakan nilai x-ms-date.
x-ms-date Jika header tidak ditentukan, tentukan Date header dalam string tanda tangan, tanpa menyertakan nama header.
Semua karakter baris baru (\n) yang ditampilkan diperlukan dalam string tanda tangan.
String tanda tangan mencakup header kanonis dan string sumber daya kanonis. Canonicalizing string ini menempatkannya ke dalam format standar yang dikenali oleh Azure Storage. Untuk informasi terperinci tentang membangun CanonicalizedHeaders string dan CanonicalizedResource yang membentuk bagian dari string tanda tangan, lihat bagian yang sesuai nanti dalam topik ini.

Blob, Antrean, dan Layanan File (otorisasi Kunci Bersama)

Untuk mengodekan string tanda tangan Kunci Bersama untuk permintaan terhadap versi 2009-09-19 dan yang lebih baru dari layanan Blob atau Antrean, dan versi 2014-02-14 dan yang lebih baru dari layanan File, gunakan format berikut:

StringToSign = VERB + "\n" +  
               Content-Encoding + "\n" +  
               Content-Language + "\n" +  
               Content-Length + "\n" +  
               Content-MD5 + "\n" +  
               Content-Type + "\n" +  
               Date + "\n" +  
               If-Modified-Since + "\n" +  
               If-Match + "\n" +  
               If-None-Match + "\n" +  
               If-Unmodified-Since + "\n" +  
               Range + "\n" +  
               CanonicalizedHeaders +   
               CanonicalizedResource;

Penting

Dalam versi saat ini, bidang Content-Length harus berupa string kosong jika panjang konten permintaan adalah nol. Dalam versi 2014-02-14 dan yang lebih lama, panjang konten disertakan bahkan jika nol. Lihat di bawah ini untuk informasi selengkapnya tentang perilaku lama.

Contoh berikut menunjukkan string tanda tangan untuk operasi Dapatkan Blob . Jika tidak ada nilai header, karakter baris baru hanya ditentukan.

GET\n\n\n\n\n\n\n\n\n\n\n\nx-ms-date:Fri, 26 Jun 2015 23:39:12 GMT\nx-ms-version:2015-02-21\n/myaccount/mycontainer\ncomp:metadata\nrestype:container\ntimeout:20

Memecah baris demi baris ini menunjukkan setiap bagian dari string yang sama:

GET\n /*HTTP Verb*/  
\n    /*Content-Encoding*/  
\n    /*Content-Language*/  
\n    /*Content-Length (empty string when zero)*/  
\n    /*Content-MD5*/  
\n    /*Content-Type*/  
\n    /*Date*/  
\n    /*If-Modified-Since */  
\n    /*If-Match*/  
\n    /*If-None-Match*/  
\n    /*If-Unmodified-Since*/  
\n    /*Range*/  
x-ms-date:Fri, 26 Jun 2015 23:39:12 GMT\nx-ms-version:2015-02-21\n    /*CanonicalizedHeaders*/  
/myaccount /mycontainer\ncomp:metadata\nrestype:container\ntimeout:20    /*CanonicalizedResource*/

Selanjutnya, kodekan string ini dengan menggunakan algoritma HMAC-SHA256 melalui string tanda tangan yang dikodekan UTF-8, buat Authorization header, dan tambahkan header ke permintaan. Contoh berikut menunjukkan Authorization header untuk operasi yang sama:

Authorization: SharedKey myaccount:ctzMq410TV3wS7upTBcunJTDLEJwMAZuFPfr0mrrA08=

Untuk menggunakan otorisasi Kunci Bersama dengan versi 2009-09-19 dan yang lebih baru dari layanan Blob dan Antrean, Anda harus memperbarui kode Anda untuk menggunakan string tanda tangan tambahan ini.

Jika Anda lebih suka memigrasikan kode Anda ke versi 2009-09-19 atau yang lebih baru dari layanan Blob dan Antrean dengan perubahan sesingkat Authorization mungkin, Anda dapat memodifikasi header yang ada untuk menggunakan Shared Key Lite alih-alih Kunci Bersama. Format tanda tangan yang diperlukan oleh Shared Key Lite identik dengan yang diperlukan untuk Kunci Bersama berdasarkan versi layanan Blob dan Antrean sebelum 2009-09-19.

Penting

Jika Anda mengakses lokasi sekunder di akun penyimpanan tempat replikasi geografis akses baca (RA-GRS) diaktifkan, jangan sertakan penandaan -secondary di header otorisasi. Untuk tujuan otorisasi, nama akun selalu merupakan nama lokasi utama, bahkan untuk akses sekunder.

Header Content-Length dalam versi 2014-02-14 dan yang lebih lama

Saat menggunakan versi 2014-02-14 atau yang lebih lama, jika Content-Length adalah nol, maka atur Content-Length bagian dari StringToSign ke 0. Biasanya ini akan menjadi string kosong.

Misalnya, untuk permintaan berikut, nilai Content-Length header disertakan dalam StringToSign bahkan ketika nol.

PUT http://myaccount/mycontainer?restype=container&timeout=30 HTTP/1.1  
x-ms-version: 2014-02-14  
x-ms-date: Fri, 26 Jun 2015 23:39:12 GMT  
Authorization: SharedKey myaccount:ctzMq410TV3wS7upTBcunJTDLEJwMAZuFPfr0mrrA08=  
Content-Length: 0

StringToSign dibangun sebagai berikut:

Version 2014-02-14 and earlier:
PUT\n\n\n\n0\n\n\n\n\n\n\n\nx-ms-date:Fri, 26 Jun 2015 23:39:12 GMT\nx-ms-version:2014-02-14\n/myaccount/mycontainer\nrestype:container\ntimeout:30

Sedangkan dalam versi setelah 2014-02-14, StringToSign harus berisi string kosong untuk Content-Length:

Version 2015-02-21 and later:
PUT\n\n\n\n\n\n\n\n\n\n\n\nx-ms-date:Fri, 26 Jun 2015 23:39:12 GMT\nx-ms-version:2015-02-21\n/myaccount/mycontainer\nrestype:container\ntimeout:30

Layanan tabel (otorisasi Kunci Bersama)

Anda harus menggunakan otorisasi Kunci Bersama untuk mengotorisasi permintaan yang dibuat terhadap layanan Table jika layanan Anda menggunakan REST API untuk membuat permintaan. Format string tanda tangan untuk Kunci Bersama terhadap layanan Table sama untuk semua versi.

String tanda tangan Kunci Bersama untuk permintaan terhadap layanan Table sedikit berbeda dari itu untuk permintaan terhadap layanan Blob atau Antrean, karena tidak menyertakan CanonicalizedHeaders bagian string. Selain itu, Date header dalam hal ini tidak pernah kosong meskipun permintaan mengatur x-ms-date header. Jika permintaan menetapkan x-ms-date, nilai tersebut juga digunakan untuk nilai Date header.

Untuk mengodekan string tanda tangan untuk permintaan terhadap layanan Table yang dibuat menggunakan REST API, gunakan format berikut:

StringToSign = VERB + "\n" +
               Content-MD5 + "\n" +
               Content-Type + "\n" +  
               Date + "\n" +  
               CanonicalizedResource;

Catatan

Dimulai dengan versi 2009-09-19, layanan Tabel mengharuskan semua panggilan REST menyertakan DataServiceVersion header dan MaxDataServiceVersion . Lihat Mengatur Header Versi Layanan Data OData untuk informasi selengkapnya.

Layanan Blob, Antrean, dan File (otorisasi Shared Key Lite)

Anda dapat menggunakan otorisasi Shared Key Lite untuk mengotorisasi permintaan yang dibuat terhadap versi 2009-09-19 dan yang lebih baru dari layanan Blob dan Antrean, dan versi 2014-02-14 dan yang lebih baru dari layanan File.

String tanda tangan untuk Shared Key Lite identik dengan string tanda tangan yang diperlukan untuk otorisasi Kunci Bersama dalam versi layanan Blob dan Antrean sebelum 2009-09-19. Jadi, jika Anda ingin memigrasikan kode Anda dengan jumlah perubahan paling sedikit pada versi 2009-09-19 dari layanan Blob dan Antrean, Anda dapat memodifikasi kode Anda untuk menggunakan Shared Key Lite, tanpa mengubah string tanda tangan itu sendiri. Dengan menggunakan Shared Key Lite, Anda tidak akan mendapatkan fungsionalitas keamanan yang ditingkatkan yang disediakan dengan menggunakan Kunci Bersama dengan versi 2009-09-19 dan yang lebih baru.

Untuk mengodekan string tanda tangan untuk permintaan terhadap layanan Blob atau Antrean, gunakan format berikut:

StringToSign = VERB + "\n" +  
               Content-MD5 + "\n" +  
               Content-Type + "\n" +  
               Date + "\n" +  
               CanonicalizedHeaders +   
               CanonicalizedResource;

Contoh berikut menunjukkan string tanda tangan untuk operasi Put Blob . Perhatikan bahwa baris header Content-MD5 kosong. Header yang ditampilkan dalam string adalah pasangan nama-nilai yang menentukan nilai metadata kustom untuk blob baru.

PUT\n\ntext/plain; charset=UTF-8\n\nx-ms-date:Sun, 20 Sep 2009 20:36:40 GMT\nx-ms-meta-m1:v1\nx-ms-meta-m2:v2\n/testaccount1/mycontainer/hello.txt

Authorization: SharedKeyLite myaccount:ctzMq410TV3wS7upTBcunJTDLEJwMAZuFPfr0mrrA08=

Layanan tabel (otorisasi Shared Key Lite)

Anda dapat menggunakan otorisasi Shared Key Lite untuk mengotorisasi permintaan yang dibuat terhadap versi layanan Tabel apa pun.

Untuk mengodekan string tanda tangan untuk permintaan terhadap layanan Table menggunakan Shared Key Lite, gunakan format berikut:

StringToSign = Date + "\n"
               CanonicalizedResource

Contoh berikut menunjukkan string tanda tangan untuk operasi Buat Tabel .

Sun, 11 Oct 2009 19:52:39 GMT\n/testaccount1/Tables

Selanjutnya, kodekan string ini dengan menggunakan algoritma HMAC-SHA256, buat Authorization header, lalu tambahkan header ke permintaan. Contoh berikut menunjukkan Authorization header untuk operasi yang sama:

Authorization: SharedKeyLite testaccount1:uay+rilMVayH/SVI8X+a3fL8k/NxCnIePdyZSkqvydM=

Membuat string header kanonis

Untuk membuat CanonicalizedHeaders bagian string tanda tangan, ikuti langkah-langkah berikut:

Ambil semua header untuk sumber daya yang dimulai dengan x-ms-, termasuk x-ms-date header .
Konversikan setiap nama header HTTP menjadi huruf kecil.
Urutkan header secara leksikografis menurut nama header, dalam urutan naik. Setiap header hanya dapat muncul sekali dalam string.

Catatan

Urutan leksikografis mungkin tidak selalu bertepatan dengan urutan alfabet konvensional.
Ganti spasi kosong linier apa pun di nilai header dengan spasi tunggal.

Spasi putih linier mencakup pengangkutan kembali/umpan baris (CRLF), spasi, dan tab. Lihat RFC 2616, bagian 4.2 untuk detailnya. Jangan ganti spasi kosong apa pun di dalam string yang dikutip.

Pangkas spasi kosong apa pun di sekitar titik dua di header .
Terakhir, tambahkan karakter baris baru ke setiap header kanonis dalam daftar yang dihasilkan. Buat CanonicalizedHeaders string dengan menggabungkan semua header dalam daftar ini menjadi satu string.

Berikut ini memperlihatkan contoh string header kanonis:

x-ms-date:Sat, 21 Feb 2015 00:48:38 GMT\nx-ms-version:2014-02-14\n

Catatan

Sebelum versi layanan 2016-05-31, header dengan nilai kosong dihilangkan dari string tanda tangan. Ini sekarang diwakili dalam CanonicalizedHeaders dengan segera mengikuti karakter titik dua dengan baris baru yang mengakhiri.

Membangun string sumber daya kanonis

Bagian CanonicalizedResource dari string tanda tangan mewakili sumber daya layanan penyimpanan yang ditargetkan oleh permintaan. Bagian apa pun dari CanonicalizedResource string yang berasal dari URI sumber daya harus dikodekan persis seperti dalam URI.

Ada dua format yang didukung untuk CanonicalizedResource string:

Format yang mendukung otorisasi Kunci Bersama untuk versi 2009-09-19 dan yang lebih baru dari layanan Blob dan Antrean, dan untuk versi 2014-02-14 dan yang lebih baru dari layanan File.
Format yang mendukung Shared Key dan Shared Key Lite untuk semua versi layanan Table, dan Shared Key Lite untuk versi 2009-09-19 dan yang lebih baru dari layanan Blob and Queue. Format ini identik dengan yang digunakan dengan versi layanan penyimpanan sebelumnya.

Untuk bantuan membangun URI untuk sumber daya yang Anda akses, lihat salah satu topik berikut:

Layanan blob: Penamaan dan Referensi Kontainer, Blob, dan Metadata
Layanan antrean: Mengatasi Sumber Daya Layanan Antrean
Layanan tabel: Mengatasi Sumber Daya Layanan Tabel
Layanan file: Penamaan dan Referensi Berbagi, Direktori, File, dan Metadata

Penting

Jika akun penyimpanan Anda direplikasi dengan replikasi geografis akses baca (RA-GRS), dan Anda mengakses sumber daya di lokasi sekunder, jangan sertakan –secondary penandaan dalam CanonicalizedResource string. URI sumber daya yang CanonicalizedResource digunakan dalam URI string harus menjadi URI sumber daya di lokasi utama.

Catatan

Jika Anda mengotorisasi terhadap emulator penyimpanan, nama akun akan muncul dua kali dalam CanonicalizedResource string. Ini yang diharapkan. Jika Anda mengotorisasi terhadap layanan penyimpanan Azure, nama akun hanya akan muncul satu kali dalam CanonicalizedResource string.

Format Kunci Bersama untuk 2009-09-19 dan yang lebih baru

Format ini mendukung otorisasi Kunci Bersama untuk versi 2009-09-19 dan yang lebih baru dari layanan Blob dan Antrean, dan versi 2014-02-14 dan yang lebih baru dari layanan File. Buat CanonicalizedResource string dalam format ini sebagai berikut:

Dimulai dengan string kosong (""), tambahkan garis miring (/), diikuti dengan nama akun yang memiliki sumber daya yang diakses.
Tambahkan jalur URI yang dikodekan sumber daya, tanpa parameter kueri apa pun.
Ambil semua parameter kueri pada URI sumber daya, termasuk comp parameter jika ada.
Konversikan semua nama parameter menjadi huruf kecil.
Urutkan parameter kueri secara leksikografis menurut nama parameter, dalam urutan naik.
Url-decode setiap nama dan nilai parameter kueri.
Sertakan karakter baris baru (\n) sebelum setiap pasangan nama-nilai.
Tambahkan setiap nama dan nilai parameter kueri ke string dalam format berikut, pastikan untuk menyertakan titik dua (:) antara nama dan nilai:

parameter-name:parameter-value
Jika parameter kueri memiliki lebih dari satu nilai, urutkan semua nilai secara leksikografis, lalu sertakan dalam daftar yang dipisahkan koma:

parameter-name:parameter-value-1,parameter-value-2,parameter-value-n

Perlu diingat aturan berikut untuk membangun string sumber daya kanonis:

Hindari menggunakan karakter baris baru (\n) dalam nilai untuk parameter kueri. Jika harus digunakan, pastikan bahwa itu tidak memengaruhi format string sumber daya kanonis.
Hindari menggunakan koma dalam nilai parameter kueri.

Berikut adalah beberapa contoh yang menunjukkan CanonicalizedResource bagian string tanda tangan, karena dapat dibangun dari URI permintaan tertentu:

Get Container Metadata  
   GET http://myaccount.blob.core.windows.net/mycontainer?restype=container&comp=metadata
CanonicalizedResource:  
    /myaccount/mycontainer\ncomp:metadata\nrestype:container  
  
List Blobs operation:  
    GET http://myaccount.blob.core.windows.net/container?restype=container&comp=list&include=snapshots&include=metadata&include=uncommittedblobs  
CanonicalizedResource:  
    /myaccount/mycontainer\ncomp:list\ninclude:metadata,snapshots,uncommittedblobs\nrestype:container  
  
Get Blob operation against a resource in the secondary location:  
   GET https://myaccount-secondary.blob.core.windows.net/mycontainer/myblob  
CanonicalizedResource:  
    /myaccount/mycontainer/myblob

Format layanan Shared Key Lite and Table untuk 2009-09-19 dan yang lebih baru

Format ini mendukung Kunci Bersama dan Kunci Bersama Lite untuk semua versi layanan Table, dan Shared Key Lite untuk versi 2009-09-19 dan yang lebih baru dari layanan Blob dan Antrean dan versi 2014-02-14 dan yang lebih baru dari layanan File. Format ini identik dengan yang digunakan dengan versi layanan penyimpanan sebelumnya. Buat CanonicalizedResource string dalam format ini sebagai berikut:

Dimulai dengan string kosong (""), tambahkan garis miring (/), diikuti dengan nama akun yang memiliki sumber daya yang diakses.
Tambahkan jalur URI yang dikodekan sumber daya. Jika URI permintaan membahas komponen sumber daya, tambahkan string kueri yang sesuai. String kueri harus menyertakan tanda tanya dan comp parameter (misalnya, ?comp=metadata). Tidak ada parameter lain yang harus disertakan pada string kueri.

Mengodekan tanda tangan

Untuk mengodekan tanda tangan, panggil algoritma HMAC-SHA256 pada string tanda tangan yang dikodekan UTF-8 dan kodekan hasilnya sebagai Base64. Perhatikan bahwa Anda juga perlu mendekode Base64 kunci akun penyimpanan Anda. Gunakan format berikut (ditampilkan sebagai pseudocode):

Signature=Base64(HMAC-SHA256(UTF8(StringToSign), Base64.decode(<your_azure_storage_account_shared_key>)))

Otorisasi dengan Kunci Bersama

Menentukan header Tanggal

Menentukan header Otorisasi

Membuat string tanda tangan

Blob, Antrean, dan Layanan File (otorisasi Kunci Bersama)

Header Content-Length dalam versi 2014-02-14 dan yang lebih lama

Layanan tabel (otorisasi Kunci Bersama)

Layanan Blob, Antrean, dan File (otorisasi Shared Key Lite)

Layanan tabel (otorisasi Shared Key Lite)

Membuat string header kanonis

Membangun string sumber daya kanonis

Format Kunci Bersama untuk 2009-09-19 dan yang lebih baru

Format layanan Shared Key Lite and Table untuk 2009-09-19 dan yang lebih baru

Mengodekan tanda tangan

Lihat juga

Sumber Daya Tambahan: