Apa sebenarnya Token Pembawa OAuth 2.0?


170

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.


Misalkan saya menerapkan penyedia otorisasi, dapatkah saya menyediakan segala jenis string untuk token pembawa? Bisakah itu string acak? Token Akses dikeluarkan melalui titik akhir OAuth 2.0 Auth0: / otorisasi dan / oauth / token. Anda dapat menggunakan pustaka yang kompatibel dengan OAuth 2.0 untuk mendapatkan Token Akses. Jika Anda belum memiliki perpustakaan OAuth 2.0 yang disukai, Auth0 menyediakan perpustakaan untuk banyak bahasa dan kerangka kerja.
Bharathkumar V

Jawaban:


146

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 noreply@example.com, 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.


2
@ Xavier Egea Bearer token pada dasarnya adalah token penyegaran Anda dan bukan token akses.
Akhil Nambiar

13
Token pembawa tidak berarti itu token penyegaran @AqeelSmith tools.ietf.org/html/rfc6750#section-6.1.1
Suman Kundu

9
Paragraf pertama menyiratkan bahwa token Pembawa adalah token penyegaran dan bukan token akses. Ini bukan kasusnya. Dari spesifikasi token Bearer "Spesifikasi ini menjelaskan cara membuat permintaan sumber daya yang dilindungi ketika token akses OAuth adalah token pembawa." RFC6750
Daniel

8
Setelah membaca jawabannya, saya juga berpikir token Bearer dan menyegarkan token adalah sama. Jawabannya harus diperbarui untuk memperjelas ini.
KurioZ7

2
Jawaban ini sangat menyesatkan. Token pembawa BUKAN Segarkan Token, seperti yang dinyatakan dalam pernyataan awal jawaban ini. Mohon perbaiki.
think01

67

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.


2
Saya tidak mengerti bagian ini: "Setelah Server Otorisasi menerima token akses, itu akan dapat mendekripsi dan membaca properti pengguna ini. Dengan cara ini, pengguna akan divalidasi dan diberikan di sepanjang semua aplikasi". Bukankah server otorisasi yang memberikan token akses, tidak menerimanya? Saya mencoba memahami masalah ini dan banyak contoh membuat perbedaan yang jelas antara server Otorisasi dan server Sumber Daya. Apa yang saya pahami adalah bahwa Anda mendapatkan token Access dari server Otorisasi dan kemudian meneruskannya bersama setiap permintaan yang Anda buat ke server sumber daya?
kivikall

1
@kivikall Anda benar. Saya sudah mengubahnya dalam jawabannya. Server Sumber Daya menerima token (Token yang telah dienkripsi oleh Server Otorisasi dalam proses pembuatan token) di setiap permintaan dan mendekripsi.
Xavier Egea

1
@kivikall Sebenarnya, untuk mendekripsi token haruslah sesuatu yang terkait dengan otorisasi, jadi itu harus menjadi milik Server Otorisasi. Itu sebabnya a menuliskannya dalam jawabannya. Namun dalam praktiknya, ini berarti bahwa dalam setiap permintaan Anda harus memvalidasi dengan Server Otorisasi token yang diterima (mungkin melakukan permintaan lain). Jadi, untuk menghindari hilangnya kinerja, lebih baik memberikan beberapa fungsi untuk mendekripsi token ke Server Sumber Daya. Periksa tautan berikutnya: stackoverflow.com/questions/12296017/…
Xavier Egea

Tetapi pada setiap permintaan, Server Sumber Daya harus memeriksa apakah AccessToken yang diberikan valid terhadap Server Otorisasi. Jadi jika suatu peran berubah, perubahan tersebut dapat langsung tercermin oleh Auth Server, bukan? Juga mengapa kita menghapus RefreshToken jika AccessToken terganggu? RefreshToken tidak dapat dihitung berdasarkan pada AccessToken, jadi ketika kadaluarsa hacker diblokir lagi.
mandarin

Seperti yang saya katakan, token akses berisi informasi pengguna, seperti peran. Jika peran pengguna berubah, perubahan ini akan tercermin di token berikutnya saat token saat ini berakhir. Ini berarti bahwa dalam waktu singkat (sampai akses token kedaluwarsa) pengguna akan mempertahankan peran yang sama dan Server Auth akan mengizinkannya karena token masih valid. Mengenai pertanyaan kedua, menghapus Refresh Token membuat pengguna memasukkan kredensial mereka lagi. Ini yang kami inginkan jika token akses dikompom. Dalam kasus lain, seorang hacker dapat diotorisasi hingga kedaluwarsa refreshtoken (untuk ex.1 bulan)
Xavier Egea

8

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


Anda tidak menjelaskan sama sekali tujuan token Pembawa.
Jaime Hablutzel
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.