OAuth grant types
OAuth grant types
What is an OAuth grant type?
Jenis pemberian OAuth menentukan urutan langkah yang tepat yang terlibat dalam proses OAuth. Jenis pemberian juga memengaruhi cara aplikasi klien berkomunikasi dengan layanan OAuth di setiap tahap, termasuk cara pengiriman token akses itu sendiri. Karena alasan ini, jenis hibah sering disebut sebagai "aliran OAuth".
Layanan OAuth harus dikonfigurasi untuk mendukung jenis hibah tertentu sebelum aplikasi klien dapat memulai aliran yang sesuai. Aplikasi klien menentukan jenis hibah yang ingin digunakan dalam permintaan otorisasi awal yang dikirimkan ke layanan OAuth.
Ada beberapa jenis hibah yang berbeda, masing-masing dengan tingkat kerumitan dan pertimbangan keamanan yang berbeda-beda. Kami akan fokus pada jenis hibah "kode otorisasi" dan "implisit" karena ini adalah yang paling umum.
OAuth scopes
Untuk jenis pemberian OAuth apa pun, aplikasi klien harus menentukan data mana yang ingin diakses dan jenis operasi yang ingin dijalankan. Ini dilakukan menggunakan parameter cakupan dari permintaan otorisasi yang dikirim ke layanan OAuth.
Untuk OAuth dasar, cakupan yang dapat diminta aksesnya oleh aplikasi klien bersifat unik untuk setiap layanan OAuth. Karena nama cakupan hanyalah string teks arbitrer, formatnya dapat sangat bervariasi antar penyedia. Beberapa bahkan menggunakan URI lengkap sebagai nama cakupan, mirip dengan titik akhir REST API. Misalnya, saat meminta akses baca ke daftar kontak pengguna, nama cakupan mungkin menggunakan salah satu dari bentuk berikut bergantung pada layanan OAuth yang digunakan:
scope=contacts
scope=contacts.read
scope=contact-list-r
scope=https://oauth-authorization-server.com/auth/scopes/user/contacts.readonly
Namun, jika OAuth digunakan untuk autentikasi, cakupan OpenID Connect standar sering digunakan sebagai gantinya. Misalnya, profil openid cakupan akan memberi aplikasi klien akses baca ke kumpulan informasi dasar yang telah ditentukan sebelumnya tentang pengguna, seperti alamat email, nama pengguna, dan sebagainya. Kami akan berbicara lebih banyak tentang OpenID Connect nanti.
Authorization code grant type
1. Authorization request
Aplikasi klien mengirimkan permintaan ke layanan OAuth / titik akhir otorisasi meminta izin untuk mengakses data pengguna tertentu. Perhatikan bahwa pemetaan titik akhir dapat bervariasi antar penyedia - lab kami menggunakan titik akhir / autentikasi untuk tujuan ini. Namun, Anda harus selalu dapat mengidentifikasi titik akhir berdasarkan parameter yang digunakan dalam permintaan.
GET
/authorization?client_id=12345&redirect_uri=https://client-app.com/callback&response_type=code&scope=openid%20profile&state=ae13d489bd00e3c24
HTTP/1.1
Host: oauth-authorization-server.com
Permintaan ini berisi parameter penting berikut, biasanya disediakan dalam string kueri:
client_id
Parameter wajib yang berisi pengenal unik dari aplikasi klien. Nilai ini dihasilkan saat aplikasi klien mendaftar dengan layanan OAuth.
redirect_uri
URI tempat browser pengguna harus diarahkan saat mengirim kode otorisasi ke aplikasi klien. Ini juga dikenal sebagai "callback URI" atau "callback endpoint". Banyak serangan OAuth didasarkan pada eksploitasi kekurangan dalam validasi parameter ini.
response_type
Menentukan jenis respons yang diharapkan aplikasi klien dan, oleh karena itu, aliran mana yang ingin dimulai. Untuk jenis pemberian kode otorisasi, nilainya harus berupa kode.
scope
Digunakan untuk menentukan subset mana dari data pengguna yang ingin diakses aplikasi klien. Perhatikan bahwa ini mungkin cakupan khusus yang ditetapkan oleh penyedia OAuth atau cakupan standar yang ditentukan oleh spesifikasi OpenID Connect. Kami akan membahas OpenID Connect lebih detail nanti.
state
Menyimpan nilai unik dan tidak dapat diperkirakan yang terkait dengan sesi saat ini pada aplikasi klien. Layanan OAuth harus mengembalikan nilai yang tepat ini dalam respons, bersama dengan kode otorisasi. Parameter ini berfungsi sebagai bentuk token CSRF untuk aplikasi klien dengan memastikan bahwa permintaan ke / callback endpoint-nya berasal dari orang yang sama yang memulai aliran OAuth.
2. User login and consent
Ketika server otorisasi menerima permintaan awal, itu akan mengarahkan pengguna ke halaman login, di mana mereka akan diminta untuk masuk ke akun mereka dengan penyedia OAuth. Misalnya, ini sering kali menjadi akun media sosial mereka.
Mereka kemudian akan disajikan dengan daftar data yang ingin diakses aplikasi klien. Ini didasarkan pada cakupan yang ditentukan dalam permintaan otorisasi. Pengguna dapat memilih apakah akan menyetujui akses ini atau tidak.
Penting untuk diperhatikan bahwa setelah pengguna menyetujui cakupan tertentu untuk aplikasi klien, langkah ini akan diselesaikan secara otomatis selama pengguna masih memiliki sesi yang valid dengan layanan OAuth. Dengan kata lain, pertama kali pengguna memilih "Masuk dengan media sosial", mereka harus masuk secara manual dan memberikan persetujuan, tetapi jika mereka mengunjungi kembali aplikasi klien nanti, mereka akan sering dapat masuk kembali dengan satu klik.
3. Authorization code grant
Jika pengguna menyetujui akses yang diminta, browser mereka akan dialihkan ke / callback endpoint yang ditentukan dalam parameter redirect_uri dari permintaan otorisasi. Permintaan GET yang dihasilkan akan berisi kode otorisasi sebagai parameter kueri. Bergantung pada konfigurasinya, itu juga dapat mengirim parameter status dengan nilai yang sama seperti dalam permintaan otorisasi.
GET /callback?code=a1b2c3d4e5f6g7h8&state=ae13d489bd00e3c24 HTTP/1.1
Host: client-app.com
4. Access token request
Setelah aplikasi klien menerima kode otorisasi, ia perlu menukarnya dengan token akses. Untuk melakukan ini, ia mengirimkan permintaan POST server-ke-server ke titik akhir token / layanan OAuth. Semua komunikasi sejak saat ini berlangsung di saluran belakang yang aman dan, oleh karena itu, biasanya tidak dapat diamati atau dikendalikan oleh penyerang.
POST /token HTTP/1.1
Host: oauth-authorization-server.com
…
client_id=12345&client_secret=SECRET&redirect_uri=https://client-app.com/callback&grant_type=authorization_code&code=a1b2c3d4e5f6g7h8
Selain client_id dan kode otorisasi, Anda akan melihat parameter baru berikut:
client_secret
Aplikasi klien harus mengautentikasi dirinya sendiri dengan memasukkan kunci rahasia yang ditetapkan saat mendaftar dengan layanan OAuth.
grant_type
Digunakan untuk memastikan titik akhir baru mengetahui jenis hibah yang ingin digunakan aplikasi klien. Dalam kasus ini, ini harus disetel ke authorization_code.
5. Access token grant
Layanan OAuth akan memvalidasi permintaan token akses. Jika semuanya seperti yang diharapkan, server merespons dengan memberi aplikasi klien token akses dengan cakupan yang diminta.
{
"access_token": "z0y9x8w7v6u5",
"token_type": "Bearer",
"expires_in": 3600,
"scope": "openid profile",
…
}
6. API call
Sekarang aplikasi klien memiliki kode akses, akhirnya dapat mengambil data pengguna dari server sumber daya. Untuk melakukannya, itu membuat panggilan API ke titik akhir / userinfo layanan OAuth. Token akses dikirimkan di header Authorization: Bearer untuk membuktikan bahwa aplikasi klien memiliki izin untuk mengakses data ini.
GET /userinfo HTTP/1.1
Host: oauth-resource-server.com
Authorization: Bearer z0y9x8w7v6u5
7. Resource grant
Server sumber daya harus memverifikasi bahwa token itu valid dan milik aplikasi klien saat ini. Jika demikian, ia akan merespons dengan mengirimkan sumber daya yang diminta, yaitu data pengguna berdasarkan cakupan token akses.
{
"username":"carlos",
"email":"carlos@carlos-montoya.net",
…
}
Aplikasi klien akhirnya dapat menggunakan data ini untuk tujuan yang dimaksudkan. Dalam kasus autentikasi OAuth, ini biasanya akan digunakan sebagai ID untuk memberi pengguna sesi yang diautentikasi, yang secara efektif memasukkan mereka.
Implicit grant type
Jenis hibah implisit jauh lebih sederhana. Daripada mendapatkan kode otorisasi terlebih dahulu dan kemudian menukarnya dengan token akses, aplikasi klien menerima token akses segera setelah pengguna memberikan persetujuannya.
Anda mungkin bertanya-tanya mengapa aplikasi klien tidak selalu menggunakan tipe hibah implisit. Jawabannya relatif sederhana - jauh lebih tidak aman. Saat menggunakan jenis hibah implisit, semua komunikasi terjadi melalui pengalihan browser - tidak ada saluran belakang yang aman seperti di aliran kode otorisasi. Ini berarti bahwa token akses sensitif dan data pengguna lebih rentan terhadap serangan potensial.
Jenis hibah implisit lebih cocok untuk aplikasi halaman tunggal dan aplikasi desktop asli, yang tidak dapat dengan mudah menyimpan client_secret di back-end, dan oleh karena itu, tidak mendapatkan banyak manfaat dari penggunaan jenis pemberian kode otorisasi.
1. Authorization request
Alur implisit dimulai dengan cara yang sama seperti aliran kode otorisasi. Satu-satunya perbedaan utama adalah bahwa parameter response_type harus disetel ke token.
GET
/authorization?client_id=12345&redirect_uri=https://client-app.com/callback&response_type=token&scope=openid%20profile&state=ae13d489bd00e3c24
HTTP/1.1
Host: oauth-authorization-server.com
2. User login and consent
Pengguna masuk dan memutuskan apakah akan menyetujui izin yang diminta atau tidak. Proses ini sama persis dengan alur kode otorisasi.
3. Access token grant
Jika pengguna memberikan persetujuan mereka untuk akses yang diminta, di sinilah segalanya mulai berbeda. Layanan OAuth akan mengarahkan browser pengguna ke redirect_uri yang ditentukan dalam permintaan otorisasi. Namun, alih-alih mengirim parameter kueri yang berisi kode otorisasi, itu akan mengirim token akses dan data khusus token lainnya sebagai fragmen URL.
GET
/callback#access_token=z0y9x8w7v6u5&token_type=Bearer&expires_in=5000&scope=openid%20profile&state=ae13d489bd00e3c24
HTTP/1.1
Host: client-app.com
Karena token akses dikirim dalam fragmen URL, itu tidak pernah dikirim langsung ke aplikasi klien. Sebaliknya, aplikasi klien harus menggunakan skrip yang sesuai untuk mengekstrak fragmen dan menyimpannya.
4. API call
Setelah berhasil mengekstrak token akses dari fragmen URL, aplikasi klien dapat menggunakannya untuk melakukan panggilan API ke endpoint / userinfo layanan OAuth. Tidak seperti di aliran kode otorisasi, ini juga terjadi melalui browser.
GET /userinfo HTTP/1.1
Host: oauth-resource-server.com
Authorization: Bearer z0y9x8w7v6u5
5. Resource grant
Server sumber daya harus memverifikasi bahwa token itu valid dan milik aplikasi klien saat ini. Jika demikian, ia akan merespons dengan mengirimkan sumber daya yang diminta, yaitu data pengguna berdasarkan cakupan yang terkait dengan token akses.
{
"username":"carlos",
"email":"carlos@carlos-montoya.net"
}
Aplikasi klien akhirnya dapat menggunakan data ini untuk tujuan yang dimaksudkan. Dalam kasus autentikasi OAuth, ini biasanya akan digunakan sebagai ID untuk memberi pengguna sesi yang diautentikasi, yang secara efektif memasukkan mereka.
Komentar
Posting Komentar