Apa sebenarnya Token Pembawa OAuth 2.0?

Menurut RFC6750 - Kerangka Otorisasi OAuth 2.0: Penggunaan Token Pembawa, token pembawa adalah:

Token keamanan dengan properti yang dimiliki oleh pihak mana pun yang memiliki token ("pembawa") dapat menggunakan token dengan cara apa pun yang dapat dilakukan oleh pihak lain yang memilikinya.

Bagi saya definisi ini tidak jelas dan saya tidak dapat menemukan spesifikasi apa pun.

• Misalkan saya menerapkan penyedia otorisasi, dapatkah saya menyediakan segala jenis string untuk token pembawa?
• Bisakah itu string acak?
• Apakah itu harus menjadi pengkodean base64 dari beberapa atribut?
  Haruskah hash?
• Dan apakah penyedia layanan perlu menanyakan penyedia otorisasi untuk memvalidasi token ini?

Terima kasih atas penunjuknya.

Bearer Token Token
keamanan dengan properti yang dapat dimiliki pihak mana pun yang memiliki token ("pembawa") menggunakan token dengan cara apa pun yang dapat dilakukan oleh pihak lain yang memilikinya. Menggunakan token pembawa tidak memerlukan pembawa untuk membuktikan kepemilikan bahan kunci kriptografi (bukti kepemilikan).

Token Pembawa dibuat untuk Anda oleh server Otentikasi. Ketika seorang pengguna mengotentikasi aplikasi Anda (klien) server otentikasi kemudian pergi dan menghasilkan untuk Anda sebuah Token. Token Pembawa adalah jenis token akses utama yang digunakan dengan OAuth 2.0. Token Pembawa pada dasarnya mengatakan "Berikan pembawa akses token ini".

The Bearer Token biasanya semacam nilai buram yang dibuat oleh server otentikasi. Itu tidak acak; itu dibuat berdasarkan pada pengguna yang memberi Anda akses dan klien aplikasi Anda mendapatkan akses.

Untuk mengakses API misalnya, Anda harus menggunakan Token Akses. Token akses berumur pendek (sekitar satu jam). Anda menggunakan token pembawa untuk mendapatkan token akses baru. Untuk mendapatkan token akses Anda mengirim server Otentikasi token pembawa ini bersama dengan id klien Anda. Dengan cara ini server tahu bahwa aplikasi yang menggunakan token pembawa adalah aplikasi yang sama dengan token pembawa dibuat. Contoh: Saya tidak bisa hanya mengambil token pembawa yang dibuat untuk aplikasi Anda dan menggunakannya dengan aplikasi saya itu tidak akan berfungsi karena tidak dihasilkan untuk saya.

Google Refresh token terlihat seperti ini: 1 / mZ1edKKACtPAb7zGlwSzvs72PvhAbGmB8K1ZrGxpcNM

disalin dari komentar: Saya tidak berpikir ada batasan pada token pembawa yang Anda berikan. Satu-satunya hal yang dapat saya pikirkan adalah menyenangkan untuk mengizinkan lebih dari satu. Misalnya pengguna dapat mengotentikasi aplikasi hingga 30 kali dan token pembawa lama masih akan berfungsi. oh dan jika seseorang belum pernah menggunakannya selama 6 bulan saya akan menghapusnya dari sistem Anda. Ini adalah server autentikasi Anda yang harus membuatnya dan memvalidasinya sehingga bagaimana formatnya terserah Anda.

Memperbarui:

Token Pembawa diatur di header Otorisasi setiap Permintaan HTTP Tindakan sebaris. Sebagai contoh:

POST /rsvp?eventId=123 HTTP/1.1
Host: events-organizer.com
Authorization: Bearer AbCdEf123456
Content-Type: application/x-www-form-urlencoded
User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/1.0 (KHTML, like Gecko; Gmail Actions)

rsvpStatus=YES

String "AbCdEf123456"dalam contoh di atas adalah token otorisasi pembawa. Ini adalah token kriptografi yang diproduksi oleh server otentikasi. Semua token pembawa yang dikirim dengan tindakan memiliki bidang masalah, dengan bidang pemirsa menentukan domain pengirim sebagai URL dari formulir https: //. Misalnya, jika email berasal dari [email protected], pemirsa adalah https://example.com .

Jika menggunakan token pembawa, verifikasi bahwa permintaan datang dari server otentikasi dan ditujukan untuk domain pengirim. Jika token tidak memverifikasi, layanan harus menanggapi permintaan dengan kode respons HTTP 401 (Tidak Diotorisasi).

Bearer Token adalah bagian dari standar OAuth V2 dan diadopsi secara luas oleh banyak API.

Ketika saya membaca pertanyaan Anda, saya telah mencoba tanpa berhasil untuk mencari di Internet bagaimana token Pembawa dienkripsi atau ditandatangani. Saya kira token pembawa tidak hash (mungkin sebagian, tetapi tidak sepenuhnya) karena dalam kasus itu, tidak akan mungkin untuk mendekripsi dan mengambil properti pengguna darinya.

Tetapi pertanyaan Anda tampaknya mencoba menemukan jawaban pada fungsionalitas token Bearer:

Misalkan saya menerapkan penyedia otorisasi, dapatkah saya menyediakan segala jenis string untuk token pembawa? Bisakah itu string acak? Apakah itu harus menjadi pengkodean base64 dari beberapa atribut? Haruskah hash?

Jadi, saya akan mencoba menjelaskan bagaimana token Bearer dan Refresh token bekerja:

Saat pengguna meminta server untuk mengirimkan token dan kata sandi pengguna melalui SSL, server mengembalikan dua hal: token akses dan token Segarkan .

Token akses adalah token Pembawa yang harus Anda tambahkan di semua header permintaan untuk diautentikasi sebagai pengguna konkret.

Authorization: Bearer <access_token>

Token Access adalah string terenkripsi dengan semua properti, Klaim, dan Peran Pengguna yang Anda inginkan. (Anda dapat memeriksa bahwa ukuran token bertambah jika Anda menambahkan lebih banyak peran atau klaim). Setelah Server Sumber Daya menerima token akses, ia akan dapat mendekripsi dan membaca properti pengguna ini. Dengan cara ini, pengguna akan divalidasi dan diberikan bersama dengan semua aplikasi.

Token akses kedaluwarsa singkat (mis. 30 menit). Jika token akses memiliki masa berlaku yang lama, itu akan menjadi masalah, karena secara teoritis tidak ada kemungkinan untuk mencabutnya. Jadi bayangkan seorang pengguna dengan peran = "Admin" yang berubah menjadi "Pengguna". Jika pengguna menyimpan token lama dengan role = "Admin" ia akan dapat mengakses hingga token kedaluwarsa dengan hak Admin. Itu sebabnya akses token memiliki kedaluwarsa singkat.

Tapi, ada satu masalah yang muncul. Jika token akses memiliki kedaluwarsa singkat, kami harus mengirimkan setiap periode singkat pengguna dan kata sandi. Apakah ini aman? Tidak. Kita harus menghindarinya. Saat itulah Refresh token muncul untuk menyelesaikan masalah ini.

Refresh token disimpan dalam DB dan akan memiliki masa berlaku lama (contoh: 1 bulan).

Seorang pengguna dapat memperoleh token akses baru (ketika kedaluwarsa, misalnya setiap 30 menit) menggunakan token penyegaran, yang telah diterima pengguna dalam permintaan pertama untuk token. Ketika token akses berakhir, klien harus mengirim token refresh. Jika token refresh ini ada di DB, server akan kembali ke klien token akses baru dan token refresh lainnya (dan akan mengganti token refresh lama dengan yang baru).

Jika token akses pengguna telah disusupi, token penyegaran dari pengguna tersebut harus dihapus dari DB. Dengan cara ini token hanya akan valid hingga token akses berakhir karena ketika peretas mencoba untuk mendapatkan token akses baru dengan mengirimkan token penyegaran, tindakan ini akan ditolak.

Token pembawa adalah satu atau lebih pengulangan dari alfabet, digit, "-", "." , "_", "~", "+", "/" diikuti oleh 0 atau lebih "=".

RFC 6750 2.1. Bidang Header Permintaan Otorisasi ( Formatnya ABNF (Augmented BNF))

The syntax for Bearer credentials is as follows:

     b64token    = 1*( ALPHA / DIGIT /
                       "-" / "." / "_" / "~" / "+" / "/" ) *"="
     credentials = "Bearer" 1*SP b64token

Sepertinya Base64 tetapi menurut Haruskah token di header menjadi base64 disandikan? , bukan itu.

Menggali lebih dalam ke "HTTP / 1.1, bagian 7: Otentikasi" **, namun, saya melihat bahwa b64token hanyalah definisi sintaks ABNF yang memungkinkan karakter yang biasanya digunakan pada base64, base64url, dll. Jadi b64token tidak tentukan setiap encoding atau decoding tetapi hanya mendefinisikan karakter apa yang dapat digunakan di bagian header Otorisasi yang akan berisi token akses.

Referensi

• RFC 5234 3.6. Pengulangan Variabel: * Aturan
• RFC 2616 2.1 Augmented BNF