Apa tujuan dari tipe otorisasi hibah implisit dalam OAuth 2?

254

Saya tidak tahu apakah saya hanya memiliki semacam blind spot atau apa, tetapi saya telah membaca spec OAuth 2 berkali-kali dan membaca arsip milis, dan saya belum menemukan penjelasan yang baik tentang mengapa Hibah Implisit aliran untuk mendapatkan token akses telah dikembangkan. Dibandingkan dengan Hibah Kode Otorisasi, tampaknya hanya menyerah pada otentikasi klien tanpa alasan yang sangat menarik. Bagaimana ini "dioptimalkan untuk klien diimplementasikan dalam browser menggunakan bahasa scripting" (mengutip spesifikasi)?

Kedua aliran memulai sama (sumber: http://tools.ietf.org/html/draft-ietf-oauth-v2-22 ):

  1. Klien memulai alur dengan mengarahkan agen pengguna pemilik sumber daya ke titik akhir otorisasi.
  2. Server otorisasi mengotentikasi pemilik sumber daya (melalui agen-pengguna) dan menetapkan apakah pemilik sumber daya mengabulkan atau menolak permintaan akses klien.
  3. Dengan asumsi pemilik sumber daya memberikan akses, server otorisasi mengarahkan kembali agen-pengguna kembali ke klien menggunakan pengalihan URI yang disediakan sebelumnya (dalam permintaan atau selama pendaftaran klien).
    • URI pengalihan termasuk kode otorisasi (Alur kode otorisasi)
    • URI pengalihan mencakup token akses dalam fragmen URI (Aliran implisit)

Di sinilah arus terbagi. Dalam kedua kasus, pengalihan URI pada titik ini adalah ke beberapa titik akhir yang dihosting oleh klien:

  • Dalam aliran kode Otorisasi, ketika agen pengguna mencapai titik akhir itu dengan kode Otorisasi di URI, kode pada titik tersebut menukar kode otorisasi bersama dengan kredensial kliennya untuk token akses yang kemudian dapat digunakan sesuai kebutuhan. Misalnya, dapat menulisnya ke halaman web yang dapat diakses oleh skrip pada halaman tersebut.
  • Aliran implisit melewatkan langkah otentikasi klien ini dan hanya memuat halaman web dengan skrip klien. Ada trik lucu di sini dengan fragmen URL yang membuat token akses tidak terlalu banyak dibagikan, tetapi hasil akhirnya pada dasarnya sama: situs yang dihosting klien menyajikan halaman dengan beberapa skrip di dalamnya yang dapat mengambil token akses .

Maka pertanyaan saya: apa yang telah diperoleh di sini dengan melewatkan langkah otentikasi klien?

oauth user-agent oauth-2.0 Dan Taflin
sumber
Lihatlah ini: ibm.com/developerworks/wikis/display/…
Håvard Geithus
5
Tautan di komentar sebelumnya sudah mati. Ini yang diperbarui
AndrewR
3
Saya sudah membaca semua jawaban di sini, tetapi saya masih tidak mengerti bagaimana tidak memerlukan rahasia klien pribadi untuk mendapatkan token akses dapat aman. Katakanlah TrustedAppDeveloper merilis TrustedPopularApp yang memungkinkan pengguna memberikannya izin (katakanlah menggunakan Twitter atau oauth) menggunakan hibah implisit. Jika saya EvilAppDeveloper, apa yang menghentikan saya membuat aplikasi yang melewatkan TrustedPopularAppId sebagai client_id dalam permintaan hibah implisit, dan kemudian melakukan tindakan (seperti mengirim spam umpan) atas nama pengguna, yang sekarang terlihat seperti berasal dari TrustedPopularApp ?
adevine
Saya ingin tahu hal yang sama seperti adevine. Tapi, kemungkinan besar aplikasi yang membutuhkan permintaan hibah implisit, tidak perlu otentikasi lebih lanjut, karena semuanya didapat?
Mave
13
@adevine Apa yang akan mencegah EvilApp dalam skenario Anda untuk mengautentikasi ke Twitter sebagai TrustedPopularApp adalah bahwa ia tidak dapat menerima panggilan balik dari Twitter, mereka akan selalu dikirim ke URI yang ditentukan saat mendaftarkan ID klien
Ivan

Jawaban:

196

Inilah pikiran saya:

Tujuan dari kode auth + token dalam aliran kode otorisasi adalah bahwa token dan rahasia klien tidak akan pernah terpapar ke pemilik sumber daya karena mereka melakukan perjalanan server-ke-server.

Di sisi lain, aliran hibah implisit adalah untuk klien yang sepenuhnya diimplementasikan menggunakan javascript dan berjalan di browser pemilik sumber daya. Anda tidak memerlukan kode sisi server apa pun untuk menggunakan alur ini. Kemudian, jika semuanya terjadi di browser pemilik sumber daya, tidak masuk akal untuk mengeluarkan kode auth & rahasia klien lagi, karena token & rahasia klien masih akan dibagikan dengan pemilik sumber daya. Termasuk kode auth & rahasia klien hanya membuat aliran lebih rumit tanpa menambahkan keamanan yang lebih nyata.

Jadi jawaban atas "apa yang telah diperoleh?" adalah "kesederhanaan".

Philip Peshin
sumber
4
Terima kasih. Itu poin yang baik bahwa dalam aliran kode otorisasi, pemilik sumber daya tidak perlu melihat token akses, sedangkan di klien javascript itu tidak dapat dihindari. Rahasia klien masih dapat disimpan dari klien javascript menggunakan aliran kode otorisasi, namun: setelah mengautentikasi dan mendapatkan token akses, kode sisi server kemudian akan meneruskan token ke klien javascript. Apa yang saya lihat sekarang, adalah bahwa aliran dana implisit memungkinkan distribusi javascript atau SDK, seperti Facebook, membebaskan pengembang dari keharusan menulis kode oauth sendiri sepenuhnya.
Dan Taflin
3
Saya mungkin akan menambahkan itu, aliran kode otorisasi memungkinkan klien untuk menyimpan token dan menggunakannya kembali. Dalam aliran implisit, Anda tidak selalu memiliki opsi itu dan karenanya, aliran implisit adalah pilihan pragmatis antara tingkat keamanan dan kenyamanan.
PålOliver
2
Ini hanya menjawab setengah, dan "apa yang hilang"?
EralpB
3
Saya tidak berpikir ini adalah jawaban yang komprehensif, aliran implisit tidak dimaksudkan untuk mendapatkan keuntungan pada kesederhanaan tetapi untuk kompromi masalah keamanan dengan aplikasi sisi klien. Auth code, bersama-sama dengan client_iddan client_secretdigunakan untuk mengidentifikasi klien tepercaya yang dapat menyegarkan token untuk login lama dan untuk "login offline" . Namun dalam aplikasi sisi klien, tidak ada cara untuk mendaftarkan setiap klien, maka jenis hibah implisit "disederhanakan" untuk akses sementara ke informasi pengguna
Chen Xie
1
Termasuk rahasia klien tidak hanya membuat aliran lebih rumit, tetapi juga membuatnya kurang aman . Rahasia klien bukanlah rahasia jika perlu disebutkan dalam kode sisi klien, dan karena itu akan diekspos ke internet. Jika ID klien Anda hanya digunakan dalam aliran tersirat, ini bukan masalah. Tetapi jika itu juga digunakan di tempat lain di platform Anda untuk penyegaran token atau hibah kode otorisasi, maka membuka rahasia terkait adalah masalah besar.
Ataraxia
94

Itu ada untuk alasan keamanan, bukan untuk kesederhanaan.

Anda harus mempertimbangkan perbedaan antara agen pengguna dan klien :

Agen-pengguna adalah perangkat lunak di mana pengguna ("pemilik sumber") berkomunikasi dengan bagian lain dari sistem (server otentikasi dan server sumber daya).

Klien adalah perangkat lunak yang ingin mengakses sumber daya pengguna di server sumber daya.

Dalam kasus agen-pengguna yang dipisahkan dan klien, Hibah Kode Otorisasi masuk akal. Misalnya pengguna menggunakan browser web (agen pengguna) untuk login dengan akun Facebooknya di Kickstarter. Dalam hal ini klien adalah salah satu server Kickstarter, yang menangani login pengguna. Server ini mendapatkan token akses dan token penyegaran dari Facebook. Jadi jenis klien ini dianggap "aman", karena akses terbatas, token dapat disimpan dan Kickstarter dapat mengakses sumber daya pengguna dan bahkan menyegarkan token akses tanpa interaksi pengguna.

Jika agen-pengguna dan klien digabungkan (misalnya aplikasi seluler asli, aplikasi javascript), Alur Kerja Otorisasi Tersirat dapat diterapkan. Itu bergantung pada kehadiran pemilik sumber daya (untuk memasukkan kredensial) dan tidak mendukung token penyegaran. Jika klien ini menyimpan token akses untuk digunakan nanti, itu akan menjadi masalah keamanan, karena token dapat dengan mudah diekstraksi oleh aplikasi lain atau pengguna klien. Tidak adanya token penyegaran merupakan petunjuk tambahan, bahwa metode ini tidak dirancang untuk mengakses sumber daya pengguna tanpa adanya pengguna.

artkoenig
sumber
2
Saya melihat browser saya telah login ke akun google saya selama berbulan-bulan. Jadi apakah Google menggunakan token akses di browser atau token akses dengan waktu kedaluwarsa yang lama? apa perbedaan penggunaan antara token akses dengan waktu kedaluwarsa yang lama dan token akses? klien lain dapat menangkap token akses dan menggunakannya ketika pemilik sumber daya tidak ada.
Mohammad Nikravan
Saya berasumsi maksud Anda perbedaan antara token penyegaran dan token akses dengan waktu kedaluwarsa yang lama ? Token penyegaran tidak boleh disimpan dalam skenario yang tidak aman, tetapi Anda dapat menyimpan token akses Anda (misalnya di penyimpanan lokal browser). Keamanan dicapai dengan menjaga masa pakai token akses Anda serendah mungkin, meskipun masih nyaman bagi pengguna Anda (mis. Anda dapat keluar secara otomatis setelah x menit tidak aktif). Jika Anda menggunakan token akses yang tahan lama, Anda praktis membuat token penyegaran menjadi usang.
artkoenig
Terima kasih atas penjelasan Anda, tetapi saya juga memiliki kebingungan lain. Saya tidak mengerti mengapa kami membutuhkan aliran "Kode Otorisasi". Kami dapat mencapai hasil yang sama di server dengan aliran implisit (access_token) dan token penyegaran. Kelihatannya satu-satunya pertimbangan keamanan aliran implisit adalah bahwa access_code harus berumur pendek sehingga tidak dapat digunakan di server ke server. Oke, tetapi token penyegaran menyelesaikan masalah ini. Mengapa kita harus menggunakan aliran auth_code dan meminta access_token dengan token itu di server untuk mendapatkan access_code ketika kita dapat mencapai hasil yang sama dengan refresh_token?
Mohammad Nikravan
"token dapat dengan mudah diekstraksi oleh aplikasi lain" Bagaimana?
mvmn
@MohammadNikravan mencari jawabannya di stackoverflow.com/q/13387698/355438
Lu55
60

Penjelasan yang biasa adalah bahwa hibah implisit lebih mudah diterapkan ketika Anda menggunakan klien JavaScript. Tapi saya pikir ini cara yang salah untuk melihatnya. Jika Anda menggunakan klien JavaScript yang meminta sumber daya yang dilindungi secara langsung melalui XMLHttpRequest, hibah implisit adalah satu-satunya pilihan Anda, meskipun kurang aman. *

Hibah Kode Otorisasi memberikan keamanan tambahan, tetapi hanya berfungsi ketika Anda memiliki server web yang meminta sumber daya yang dilindungi. Karena server web dapat menyimpan token akses, Anda menjalankan lebih sedikit risiko token akses yang terekspos ke Internet, dan Anda dapat mengeluarkan token yang tahan lama. Dan karena server web tepercaya, ia dapat diberi "token penyegaran", sehingga bisa mendapatkan token akses baru ketika yang lama kedaluwarsa.

Tapi - dan ini adalah hal yang mudah dilewatkan - keamanan aliran kode Otorisasi hanya berfungsi jika server web dilindungi dengan sesi, yang dibuat dengan otentikasi pengguna (login). Tanpa sesi, pengguna yang tidak dipercaya bisa membuat permintaan ke server web, menggunakan client_id, dan itu akan sama seperti jika pengguna memiliki token akses. Menambahkan sesi berarti bahwa hanya pengguna yang diautentikasi yang dapat mengakses sumber daya yang dilindungi. Client_id hanyalah "identitas" dari webapp JS, bukan otentikasi dari webapp tersebut.

Ini juga berarti bahwa Anda dapat mengakhiri sesi sebelum token OAuth berakhir. Tidak ada cara standar untuk membatalkan token akses. Tetapi jika sesi Anda berakhir, token akses tidak berguna, karena tidak ada yang tahu kecuali server web. Jika pengguna yang tidak dipercaya mendapatkan akses ke kunci sesi Anda, mereka hanya akan dapat mengakses sumber daya yang dilindungi selama sesi itu valid.

Jika tidak ada server web, Anda harus menggunakan hibah Tersirat. Tetapi ini berarti bahwa token akses terpapar ke Internet. Jika pengguna yang tidak dipercaya mendapatkan akses ke sana, mereka dapat menggunakannya sampai habis masa berlakunya. Ini berarti mereka akan memiliki akses lebih lama daripada dengan hibah Kode Otorisasi. Jadi, Anda mungkin ingin mempertimbangkan untuk membuat token lebih cepat berakhir, dan menghindari memberikan akses ke sumber daya yang lebih sensitif.

* EDIT: Baru-baru ini, orang merekomendasikan agar Anda tidak menggunakan hibah Implisit, bahkan pada aplikasi web tanpa server. Alih-alih, Anda dapat menggunakan hibah Kode Otorisasi yang dikonfigurasi dengan rahasia kosong, bersama dengan PKCE. Pemberian kode autentik menghindari penyimpanan token akses dalam riwayat browser Anda, dan PKCE menghindarinya jika seseorang membajak URL pengalihan untuk mencuri kode auth. Dalam hal ini Anda perlu server untuk menghindari pengembalian token penyegaran, karena klien Anda mungkin tidak dapat menyimpannya dengan aman. Dan itu harus mengeluarkan token akses dengan batasan yang sama yang disebutkan di atas.

JW.
sumber
21

Itu bermuara pada: Jika pengguna menjalankan aplikasi web berbasis, atau "publik", JavaScript tanpa komponen sisi server, maka pengguna secara implisit mempercayai aplikasi (dan browser tempat aplikasi berjalan, berpotensi dengan browser lain aplikasi berbasis ...).

Tidak ada server jarak jauh pihak ke-3, hanya server sumber daya. Tidak ada manfaat untuk kode otorisasi, karena tidak ada agen lain selain browser yang bertindak atas nama pengguna. Tidak ada manfaat untuk kredensial klien karena alasan yang sama. ( Setiap klien dapat mencoba untuk menggunakan aliran ini.)

Namun, implikasi keamanannya penting. Dari http://tools.ietf.org/html/rfc6749#section-10.3 :

Saat menggunakan jenis hibah implisit, token akses ditransmisikan dalam fragmen URI, yang dapat memaparkannya kepada pihak yang tidak berwenang.

Dari http://tools.ietf.org/html/rfc6749#section-10.16 :

Pemilik sumber daya dapat dengan sukarela mendelegasikan akses ke sumber daya dengan memberikan token akses ke klien jahat penyerang. Ini mungkin karena phishing atau alasan lain ...

Akan
sumber
apa yang Anda maksud dengan aplikasi web "publik", (JavaScript) tanpa komponen sisi server? Bagaimana bisa ada aplikasi web tanpa server?
Zammy Page
2
@ZammyPage, inilah yang sering disebut Aplikasi Halaman Tunggal (SPA). Keseluruhan aplikasi dilayani dari sumber daya statis. Javascript dalam aplikasi kemudian secara dinamis mengakses sumber daya apa pun yang dibutuhkan, pada server sumber daya apa pun yang dapat diaksesnya. Tidak ada server yang menghasilkan konten klien: javascript di klien memodifikasi DOM yang diperlukan untuk mewakili sumber daya yang telah diakses.
Elroy Flynn
13

Saya tidak yakin saya mengerti dengan benar jawaban dan komentar Dan. Tampaknya bagi saya bahwa jawabannya telah menyatakan beberapa fakta yang benar tetapi itu menunjukkan dengan tepat apa yang ditanyakan OP. Jika saya mengerti dengan benar, keuntungan utama dari aliran hibah implisit adalah bahwa klien seperti aplikasi JS (mis. Ekstensi Chrome) tidak harus membuka rahasia klien.

Dan Taflin berkata:

... dalam aliran kode otorisasi, pemilik sumber daya tidak perlu melihat token akses, sedangkan pada klien javascript yang tidak dapat dihindari. Rahasia klien masih dapat disimpan dari klien javascript menggunakan aliran kode otorisasi, namun ..

Mungkin saya salah paham dengan Anda, tetapi klien (aplikasi JS dalam kasus ini) harus menyerahkan kredensial klien (kunci dan rahasia klien) ke server sumber daya dalam aliran kode otorisasi, bukan? Rahasia klien tidak dapat "disimpan dari JS".

tzuchien.chiu
sumber
6
Saya menyadari ini adalah pertanyaan lama tetapi ini adalah jawaban yang lebih baik daripada yang diterima. Alasan Hibah Tersirat ada adalah bahwa klien javascript tidak dapat menyimpan rahasia, dan karenanya tidak dapat dikonfirmasi. Jadi server otorisasi harus hanya mengandalkan registrasi redirect uri dan agen pengguna untuk keamanan. Anda meneruskan token otorisasi hanya ke agen pengguna, dan hanya pada uri pengalihan tertentu, secara teoritis mencegah intersepsi (karena pengguna jahat yang tidak memiliki domain uri pengalihan tidak dapat menjalankan kode dalam agen pengguna di uri itu).
gregates
Memang jawaban yang diterima membuatku bingung. Membuat saya berpikir saya salah memahami apa itu client_secret! Jawaban ini dan komentar di atas tepat.
Sarsaparilla
9

Sementara Hibah Implisit dirancang untuk mendukung aplikasi yang tidak dapat melindungi rahasia klien termasuk aplikasi JavaScript sisi klien, beberapa penyedia menerapkan alternatif menggunakan Kode Otorisasi tanpa Rahasia Klien. OAuth 2.0 IETF RFC-6749 diterbitkan pada 2012 dan rekomendasi saat ini beberapa diskusi baru-baru ini berasal dari 2017.

Diskusi 2017 tentang milis IETF OAuth tersedia dari para pelaksana ini:

Baca lebih lanjut di sini:

Implisit sebelumnya direkomendasikan untuk klien tanpa rahasia, tetapi telah digantikan dengan menggunakan hibah Kode Otorisasi tanpa rahasia.

...

Sebelumnya, direkomendasikan bahwa aplikasi berbasis browser menggunakan aliran "Tersirat", yang segera mengembalikan token akses dan tidak memiliki langkah pertukaran token. Pada waktu sejak spesifikasi awalnya ditulis, praktik terbaik industri telah berubah untuk merekomendasikan agar aliran kode otorisasi digunakan tanpa rahasia klien. Ini memberikan lebih banyak peluang untuk membuat aliran aman, seperti menggunakan parameter status. Referensi: Redhat , Deutsche Telekom , Smart Health IT .

Pindah ke Kode Auth tanpa Rahasia Klien dari Implicit Grant juga disebutkan untuk aplikasi seluler di sini:

Grokify
sumber
Saya pikir Anda ingin berhati-hati dengan rekomendasi ini. Ini direkomendasikan dalam panduan untuk aplikasi asli, bukan spa. Sayangnya tidak ada panduan yang baik tentang SPA seperti yang didokumentasikan dalam banyak diskusi online, forum dan bahkan milis oauth-wg.
Tom
Rekomendasi untuk pindah ke kode auth tanpa rahasia dari pemberian implisit adalah rekomendasi untuk SPA dan aplikasi seluler, tetapi kutipan saya di atas khusus untuk SPA. Artikel yang direferensikan menggunakan teks yang sama untuk SPA dan aplikasi seluler, tetapi dengan bahasa "aplikasi berbasis browser" "aplikasi seluler dan asli" di teks masing-masing. Juga referensi untuk Redhat, DT, Smart Health IT, khusus untuk SPA dan tidak termasuk dalam catatan untuk aplikasi seluler. Saya telah menambahkan tautan dalam ke SPA di jawaban untuk membuatnya lebih mudah ditemukan. Silakan kirim beberapa tautan ke diskusi yang Anda sebutkan.
Grokify
Diskusi oauth-wg yang cukup baru (2018) dapat ditemukan di sini ietf.org/mail-archive/web/oauth/current/msg18020.html . RFC 8252 adalah untuk aplikasi asli karena judulnya menunjukkan "OAuth 2.0 untuk Aplikasi Asli". Referensi ke Redhat, DT, Smart Health IT adalah tanggapan terhadap diskusi milis, bukan rfc, draft kerja, dll ...
Tom
3

selain jawaban lain, penting juga untuk menyadari bahwa profil Implisit memungkinkan aliran saluran-depan hanya berlawanan dengan aliran Kode Otorisasi yang memerlukan panggilan kembali ke Server Otorisasi; ini menjadi jelas dalam OpenID Connect yang merupakan protokol SSO yang dibangun di atas Auth 2.0 di mana aliran implisit menyerupai SAML POST mengikat cukup populer dan aliran Kode Otorisasi menyerupai SAML Artifact mengikat kurang diterapkan

Hans Z.
sumber
3

Dalam aliran implisit jika browser pengguna rusak (ekstensi jahat / virus) maka korupsi mendapatkan akses ke sumber daya pengguna dan dapat melakukan hal-hal buruk.

Dalam auth flow, korupsi tidak bisa karena tidak tahu rahasia klien.

Kecepatan
sumber
2

https://tools.ietf.org/html/rfc6749#page-8

Implisit

Hibah implisit adalah aliran kode otorisasi sederhana yang dioptimalkan untuk klien yang diimplementasikan dalam browser menggunakan bahasa scripting seperti JavaScript. Dalam aliran tersirat, alih-alih mengeluarkan kode otorisasi klien, klien diberikan token akses secara langsung (sebagai hasil dari otorisasi pemilik sumber daya). Jenis hibah tersirat, karena tidak ada kredensial menengah (seperti kode otorisasi) yang dikeluarkan (dan kemudian digunakan untuk mendapatkan token akses).

Saat mengeluarkan token akses selama aliran hibah implisit,
server otorisasi tidak mengautentikasi klien. Dalam beberapa
kasus, identitas klien dapat diverifikasi melalui URI pengalihan yang
digunakan untuk mengirimkan token akses ke klien. Token akses dapat terpapar ke pemilik sumber daya atau aplikasi lain dengan akses ke agen pengguna pemilik sumber daya.

Hibah implisit meningkatkan respons dan efisiensi beberapa
klien (seperti klien yang diimplementasikan sebagai aplikasi dalam peramban),
karena itu mengurangi jumlah perjalanan bolak-balik yang diperlukan untuk mendapatkan
token akses.

Rzv Razvan
sumber
1

Saya pikir Will Cain menjawab ini ketika dia berkata, "Tidak ada manfaat bagi kredensial klien untuk alasan yang sama. (Klien mana pun dapat mencoba menggunakan aliran ini.)" Juga pertimbangkan bahwa redirect_uri untuk aliran implisit mungkin "localhost" - tidak ada panggilan balik dibuat dari Server Otorisasi untuk aliran implisit. Karena tidak ada cara untuk mempercayai klien, pengguna harus menyetujui pelepasan klaim pengguna.

Mike Schwartz
sumber
1

Hibah Implisit memungkinkan untuk memperoleh token dari Titik Akhir Otorisasi dengan a GET. Ini berarti server otorisasi tidak harus mendukung CORS.

Jika itu bukan masalah dan tidak ada masalah lain yang terkait dengan server otorisasi tidak fleksibel (mis. Token penyegaran tidak opsional, untuk beberapa alasan) maka aliran kode otorisasi adalah yang lebih disukai, bahkan untuk klien publik, sesuai dengan tren industri terkini dan setidaknya contoh (saat ini) dari draft resmi .

Secara historis ada alasan lain untuk menerapkan aliran implisit tetapi tampaknya mereka saat ini lebih besar daripada manfaat keamanan yang diberikan oleh kode otorisasi, termasuk:

  • opsi untuk mengirim dan menggunakan token melalui saluran belakang untuk klien rahasia
  • tidak memperlihatkan token dalam riwayat browser untuk klien publik
  • mengganggu aliran yang tidak sah sebelum token dikeluarkan - dengan PKCE , untuk "semua jenis klien OAuth"
ko la
sumber
0

Saya baru saja dihadapkan dengan beberapa artikel tentang OAuth 2.0. Penulis menyatakan bahwa alasan di balik aliran Implisit adalah bahwa aplikasi JS sangat terbatas dalam permintaan di sana:

jika Anda bertanya-tanya mengapa tipe implisit dimasukkan dalam OAuth 2.0, penjelasannya sederhana: Kebijakan Asal Sama. Saat itu, aplikasi frontend tidak diizinkan untuk mengirim permintaan ke host yang berbeda untuk mendapatkan token akses menggunakan kode. Hari ini kami memiliki CORS (Cross-Origin Resource Sharing).

https://medium.com/securing/what-is-going-on-with-oauth-2-0-and-why-you-should-not-use-use-it-for-authentication-5f47597b2611

Lu55
sumber