Bagaimana seharusnya API menggunakan otentikasi dasar http

Ketika API mengharuskan klien mengautentikasi ke dalamnya, saya telah melihat dua skenario berbeda yang digunakan dan saya ingin tahu kasus mana yang harus saya gunakan untuk situasi saya.

Contoh 1. API ditawarkan oleh perusahaan untuk memungkinkan pihak ketiga untuk mengautentikasi dengan token dan rahasia menggunakan HTTP Basic.

Contoh 2. API menerima nama pengguna dan kata sandi melalui HTTP Basic untuk mengautentikasi pengguna akhir. Umumnya mereka mendapatkan token kembali untuk permintaan di masa depan.

Pengaturan Saya: Saya akan memiliki API JSON yang saya gunakan sebagai backend saya untuk aplikasi seluler dan web. Sepertinya praktik yang baik untuk aplikasi seluler dan web mengirimkan tanda dan rahasia sehingga hanya dua aplikasi ini yang dapat mengakses API yang memblokir pihak ketiga mana pun.

Tetapi aplikasi seluler dan web memungkinkan pengguna untuk masuk dan mengirim posting, melihat data mereka, dll. Jadi saya ingin mereka juga masuk melalui HTTP Basic pada setiap permintaan.

Apakah saya entah bagaimana menggunakan kombinasi kedua metode ini atau hanya mengirim kredensial pengguna akhir (nama pengguna dan token) pada setiap permintaan? Jika saya hanya mengirim kredensial pengguna akhir, apakah saya menyimpannya dalam cookie pada klien?

api rest authentication

— Paul Sylling
sumber

Perhatikan bahwa cookie bukan bagian dari protokol HTTP, dan hanyalah fitur browser yang umum. Jadi, jika Anda tidak menggunakan untuk web, lupakan saja.

— Yam Marcovic

Jika cookie tidak direkomendasikan, bagaimana / di mana Anda menyimpan kredit untuk diteruskan ke api?

— Paul Sylling

Cookie hanyalah cara bagi pengguna browser untuk menyimpan token sesi dengan mulus. Jika Anda berinteraksi dengan pengembang, ini tidak harus mulus. Anda dapat mengatur layanan koneksi publik yang memberikan "tiket", dan pengembang dapat menyimpan tiket mereka dalam memori atau di mana pun mereka mau. Perhatikan bahwa saya tidak memiliki pengalaman layanan web praktis dan mungkin ada solusi standar untuk hal semacam ini.

— Yam Marcovic

Apa pendapat Anda tentang pertanyaan saya tentang pengguna akhir auth dan api auth. Saya masih tidak yakin dengan ini

— Paul Sylling

Jawaban:

Otentikasi dasar HTTP mengharuskan nama pengguna dan kata sandi dikirimkan bersama setiap permintaan sumber daya. Nama pengguna: kata sandi dilewatkan dalam string "Permintaan" header base64 yang disandikan diawali dengan "Dasar". Jika semua komunikasi http Anda dienkripsi (melalui ssl) informasi kepala Otorisasi seharusnya tidak dapat dengan mudah digunakan oleh penyerang karena tidak mungkin mereka akan dapat memperolehnya.

Http terenkripsi SSL dengan otentikasi dasar harus cukup.

— Nathan Pilling
sumber

dapatkah Anda memberikan contohnya? Itu yang saya butuhkan, hanya SANGAT macet sekarang ...

— ganders

Bisakah OAuth / OpenID bekerja, bersama dengan token / rahasia?

Saya baru-baru ini merenungkan skenario berikut:

Ujung Depan Aplikasi Web
API REST yang mendasarinya
Aplikasi Perangkat Seluler, mengakses REST API

Sebagai tes sederhana, saya dapat:

Otentikasi pengguna melalui Aplikasi Web menggunakan OAuth
API REST diotorisasi melalui OAuth, menghasilkan rahasia yang dihasilkan dan diteruskan ke klien
Perangkat Seluler kemudian akan mengautentikasi melalui OAuth, dan kemudian disahkan oleh REST API melalui rahasia

Ini akan memungkinkan Aplikasi Perangkat Seluler untuk mengautentikasi dengan kredensial yang sama seperti melalui Web Front End (akun yang sama) dan juga dapat mengotorisasi akses ke API.

— Brendan Green
sumber

Jadi, dalam contoh Anda, hanya pengguna yang mengautentikasi. Klien yang melakukan panggilan ke API (aplikasi web, aplikasi seluler) tidak mengautentikasi siapa mereka. Secara teoritis, API bersifat publik dan aplikasi apa pun dapat memposting nama pengguna dan kata sandi dan berpotensi mendapatkan token kembali

— Paul Sylling

Pengguna mengautentikasi melalui Aplikasi, dan aplikasi melakukan panggilan atas nama pengguna. Proses otentikasi mendapatkan token, yang kemudian diteruskan oleh aplikasi.

— Brendan Green