Gambaran

Saya ingin membuat API (REST) ​​untuk aplikasi saya. Tujuan awal / utama adalah untuk konsumsi oleh aplikasi seluler (iPhone, Android, Symbian, dll). Saya telah mencari mekanisme berbeda untuk otentikasi dan otorisasi untuk API berbasis web (dengan mempelajari implementasi lainnya). Kepalaku terlilit sebagian besar konsep dasar tetapi saya masih mencari bimbingan di beberapa bidang. Hal terakhir yang ingin saya lakukan adalah menemukan kembali roda, tetapi saya tidak menemukan solusi standar yang sesuai dengan kriteria saya (namun kriteria saya salah kaprah, jadi jangan ragu untuk mengkritiknya juga). Selain itu, saya ingin API sama untuk semua platform / aplikasi yang menggunakannya.

o Ya

Saya akan melanjutkan dan membuang keberatan saya untuk oAuth karena saya tahu itu akan menjadi solusi pertama yang ditawarkan. Untuk aplikasi seluler (atau lebih khusus aplikasi non-web), sepertinya salah meninggalkan aplikasi (pergi ke browser web) untuk otentikasi. Selain itu, tidak ada cara (saya tahu) untuk browser untuk mengembalikan panggilan balik ke aplikasi (terutama lintas platform). Saya tahu beberapa aplikasi yang melakukan itu, tetapi hanya terasa salah dan memberikan istirahat pada aplikasi UX.

Persyaratan

1. Pengguna memasukkan nama pengguna / kata sandi ke dalam aplikasi.
2. Setiap panggilan API diidentifikasi oleh aplikasi panggilan.
3. Overhead dijaga agar tetap minimum dan aspek authtif intuitif untuk pengembang.
4. Mekanisme ini aman untuk pengguna akhir (kredensial login mereka tidak diekspos) maupun pengembang (kredensial aplikasi mereka tidak diekspos).
5. Jika memungkinkan, tidak memerlukan https (tidak berarti persyaratan sulit).

Pikiran Saya Saat Ini tentang Implementasi

Pengembang eksternal akan meminta akun API. Mereka akan menerima apikey dan apisecret. Setiap permintaan akan membutuhkan minimal tiga parameter.

• apikey - diberikan kepada pengembang saat pendaftaran
• timestamp - berfungsi sebagai pengidentifikasi unik untuk setiap pesan untuk apikey yang diberikan
• hash - hash cap waktu + apisecret

Apikey diperlukan untuk mengidentifikasi aplikasi yang mengeluarkan permintaan. Timestamp bertindak serupa dengan oauth_nonce dan menghindari / mengurangi serangan replay. Hash memastikan bahwa permintaan benar-benar dikeluarkan dari pemilik apikey yang diberikan.

Untuk permintaan terotentikasi (yang dilakukan atas nama pengguna), saya masih ragu-ragu antara pergi dengan rute access_token atau kombo hash nama pengguna dan kata sandi. Apa pun itu, pada suatu titik suatu kombo nama pengguna / kata sandi akan diperlukan. Jadi ketika itu terjadi, hash dari beberapa bagian informasi (apikey, apisecret, timestamp) + kata sandi akan digunakan. Saya suka umpan balik tentang aspek ini. FYI, mereka harus memilah password terlebih dahulu, karena saya tidak menyimpan kata sandi di sistem saya tanpa hashing.

Kesimpulan

FYI, ini bukan permintaan untuk bagaimana membangun / menyusun API secara umum hanya bagaimana menangani otentikasi dan otorisasi hanya dari dalam suatu aplikasi.

Pikiran Acak / Pertanyaan Bonus

Untuk API yang hanya memerlukan apikey sebagai bagian dari permintaan, bagaimana Anda mencegah orang lain selain pemilik apikey untuk dapat melihat apikey (sejak dikirim di tempat yang jelas) dan membuat permintaan berlebihan untuk mendorong mereka melewati batas penggunaan? Mungkin saya hanya memikirkan hal ini, tetapi tidakkah seharusnya ada sesuatu untuk mengotentikasi bahwa permintaan telah diverifikasi kepada pemilik yang benar? Dalam kasus saya, itulah tujuan dari apisecret, tidak pernah ditampilkan / ditransmisikan tanpa hash.

Berbicara tentang hash, bagaimana dengan MD5 vs hmac-sha1? Apakah itu benar-benar penting ketika semua nilai hash dengan data yang cukup panjang (mis. Apisecret)?

Saya sebelumnya telah mempertimbangkan untuk menambahkan garam per pengguna / baris ke hash kata sandi pengguna saya. Jika saya melakukan itu, bagaimana mungkin aplikasi dapat membuat hash yang cocok tanpa mengetahui garam yang digunakan?

Cara saya berpikir untuk melakukan bagian login ini di proyek saya adalah:

1. sebelum login, pengguna meminta login_tokendari server. Ini dihasilkan dan disimpan di server berdasarkan permintaan, dan mungkin memiliki masa hidup yang terbatas.

2. untuk masuk aplikasi menghitung hash kata sandi pengguna, lalu hash kata sandi dengan login_tokenuntuk mendapatkan nilai, mereka kemudian mengembalikan login_tokenhash gabungan dan.

3. Server memeriksa login_tokenapakah ia telah dihasilkan, menghapusnya dari daftar login_tokens yang valid . Server kemudian menggabungkan hash yang tersimpan dari kata sandi pengguna dengan login_tokendan memastikan bahwa itu cocok dengan token gabungan yang dikirimkan. Jika cocok, Anda telah mengautentikasi pengguna Anda.

Keuntungan dari ini adalah bahwa Anda tidak pernah menyimpan kata sandi pengguna di server, kata sandi tidak pernah lulus dengan jelas, kata sandi hash hanya diteruskan secara jelas pada pembuatan akun (meskipun mungkin ada cara-cara di sekitar ini), dan harus aman dari serangan replay karena login_tokendihapus dari DB yang digunakan.

Itu banyak sekali pertanyaan dalam satu, saya kira beberapa orang tidak berhasil membaca sampai akhir :)

Pengalaman saya tentang otentikasi layanan web adalah bahwa orang biasanya overengineer, dan masalahnya hanya sama seperti yang Anda temui di halaman web. Kemungkinan opsi yang sangat sederhana akan mencakup https untuk langkah login, mengembalikan token, mengharuskannya untuk disertakan dengan permintaan di masa depan. Anda juga bisa menggunakan autentikasi dasar http, dan hanya meneruskan barang di header. Untuk keamanan tambahan, putar / kedaluwarsa token sering, periksa permintaan berasal dari blok IP yang sama (ini bisa berantakan meskipun pengguna seluler bergerak antar sel), digabungkan dengan kunci API atau serupa. Sebagai alternatif, lakukan langkah "kunci permintaan" pada oauth (seseorang telah menyarankan ini di jawaban sebelumnya dan ini merupakan ide yang baik) sebelum mengautentikasi pengguna, dan menggunakannya sebagai kunci yang diperlukan untuk menghasilkan token akses.

Alternatif yang belum saya gunakan tetapi saya telah mendengar banyak tentang sebagai alternatif yang ramah perangkat untuk oAuth adalah xAuth . Lihat itu dan jika Anda menggunakannya maka saya akan sangat tertarik untuk mendengar apa kesan Anda.

Untuk hashing, sha1 sedikit lebih baik tetapi jangan menutupinya - apa pun perangkat dapat dengan mudah (dan dengan cepat dalam arti kinerja) implementasi mungkin baik-baik saja.

Semoga itu bisa membantu, semoga berhasil :)

Jadi yang Anda cari adalah semacam mekanisme otentikasi sisi server yang akan menangani aspek otentikasi dan otorisasi aplikasi seluler?

Dengan asumsi inilah masalahnya, maka saya akan mendekatinya sebagai berikut (tetapi hanya karena saya adalah pengembang Java sehingga seorang C # guy akan melakukannya secara berbeda):

Layanan otentikasi dan otorisasi yang tenang

1. Ini hanya akan berfungsi pada HTTPS untuk mencegah penyadapan.
2. Ini akan didasarkan pada kombinasi RESTEasy , Spring Security dan CAS (untuk sistem masuk tunggal di beberapa aplikasi).
3. Ini akan bekerja dengan browser dan aplikasi klien yang mendukung web
4. Akan ada antarmuka manajemen akun berbasis web untuk memungkinkan pengguna mengedit detail mereka, dan admin (untuk aplikasi tertentu) untuk mengubah tingkat otorisasi

Pustaka / aplikasi keamanan sisi klien

1. Untuk setiap platform yang didukung (mis. Symbian, Android, iOS dll) buat implementasi yang sesuai dari perpustakaan keamanan dalam bahasa asli platform (misalnya Java, ObjectiveC, C dll)
2. Perpustakaan harus mengelola formasi permintaan HTTPS menggunakan API yang tersedia untuk platform yang diberikan (mis. Java menggunakan URLConnection dll)
3. Konsumen dari perpustakaan otentikasi dan otorisasi umum (karena hanya itu saja) akan kode ke antarmuka tertentu dan tidak akan senang jika itu pernah berubah jadi pastikan itu sangat fleksibel. Ikuti pilihan desain yang ada seperti Spring Security.

Jadi sekarang setelah melihat dari 30.000 kaki selesai bagaimana Anda melakukannya? Yah, tidak sulit untuk membuat sistem otentikasi dan otorisasi berdasarkan teknologi yang terdaftar di sisi server dengan klien browser. Dalam kombinasi dengan HTTPS, kerangka kerja akan memberikan proses yang aman berdasarkan token bersama (biasanya disajikan sebagai cookie) yang dihasilkan oleh proses otentikasi dan digunakan setiap kali pengguna ingin melakukan sesuatu. Token ini disajikan oleh klien ke server setiap kali ada permintaan.

Dalam hal aplikasi seluler lokal, tampaknya Anda mencari solusi yang melakukan hal berikut:

1. Aplikasi klien memiliki Daftar Kontrol Akses (ACL) yang ditentukan untuk mengontrol akses runtime ke panggilan metode. Misalnya, pengguna yang diberikan dapat membaca koleksi dari suatu metode, tetapi ACL mereka hanya mengizinkan akses ke objek yang memiliki Q di namanya sehingga beberapa data dalam koleksi cukup menarik oleh pencegat keamanan. Di Jawa ini sangat mudah, Anda cukup menggunakan anotasi Spring Security pada kode panggilan dan menerapkan proses respons ACL yang sesuai. Dalam bahasa lain, Anda sendirian dan mungkin perlu memberikan kode keamanan boilerplate yang memanggil ke perpustakaan keamanan Anda. Jika bahasa mendukung AOP (Pemrograman Berorientasi Aspek) maka gunakan sepenuhnya untuk situasi ini.
2. Pustaka keamanan menyimpan daftar otorisasi lengkap ke dalam memori pribadi untuk aplikasi saat ini sehingga tidak harus tetap terhubung. Bergantung pada panjang sesi login, ini bisa menjadi operasi satu kali yang tidak pernah diulang.

Apa pun yang Anda lakukan, jangan mencoba untuk menciptakan protokol keamanan Anda sendiri , atau gunakan keamanan dengan ketidakjelasan. Anda tidak akan pernah bisa menulis algoritma yang lebih baik untuk ini daripada yang saat ini tersedia dan gratis. Juga, orang mempercayai algoritma terkenal. Jadi jika Anda mengatakan bahwa perpustakaan keamanan Anda memberikan otorisasi dan otentikasi untuk aplikasi seluler lokal menggunakan kombinasi SSL, HTTPS, SpringSecurity dan token terenkripsi AES maka Anda akan segera memiliki kredibilitas di pasar.

Semoga ini bisa membantu, dan semoga sukses dengan usaha Anda. Jika Anda ingin info lebih lanjut, beri tahu saya - Saya telah menulis beberapa aplikasi web berdasarkan Spring Security, ACL, dan sejenisnya.

Twitter membahas masalah aplikasi eksternal di oAuth dengan mendukung varian yang mereka sebut xAuth . Sayangnya sudah ada banyak skema lain dengan nama ini sehingga bisa membingungkan untuk memilah.

Protokolnya adalah oAuth, kecuali ia melompati fase token permintaan dan langsung mengeluarkan pasangan token akses setelah menerima nama pengguna dan kata sandi. (Mulai dari langkah E di sini .) Permintaan dan respons awal ini harus diamankan- mengirim nama pengguna dan kata sandi dalam plaintext dan menerima kembali token akses dan token rahasia. Setelah pasangan token akses telah dikonfigurasi, apakah pertukaran token awal adalah melalui model oAuth atau model xAuth tidak relevan bagi klien dan server selama sisa sesi. Ini memiliki keuntungan bahwa Anda dapat memanfaatkan infrastruktur oAuth yang ada dan memiliki implementasi yang hampir sama untuk aplikasi seluler / web / desktop. Kerugian utama adalah aplikasi diberikan akses ke nama pengguna dan kata sandi klien, tetapi tampaknya persyaratan Anda mengharuskan pendekatan ini.

Bagaimanapun, saya ingin setuju dengan intuisi Anda dan beberapa penjawab lain di sini: jangan mencoba untuk membangun sesuatu yang baru dari awal. Protokol keamanan bisa mudah dimulai tetapi selalu sulit dilakukan dengan baik, dan semakin berbelit-belit, semakin kecil kemungkinan pengembang pihak ketiga Anda dapat menerapkannya. Protokol hipotetis Anda sangat mirip dengan o (x) Auth - api_key / api_secret, nonce, sha1 hashing - tetapi alih-alih dapat menggunakan salah satu dari banyak perpustakaan yang ada, pengembang Anda perlu menggulirkannya sendiri.

Sangat terlambat ke pesta tetapi saya ingin memberikan beberapa poin tambahan untuk dipertimbangkan bagi siapa saja yang tertarik dengan masalah ini. Saya bekerja untuk perusahaan yang melakukan solusi keamanan API seluler ( approov ) sehingga seluruh area ini jelas relevan dengan minat saya.

Untuk mulai dengan, hal paling penting untuk dipertimbangkan ketika mencoba untuk mengamankan API seluler adalah berapa nilainya bagi Anda . Solusi yang tepat untuk bank berbeda dengan solusi yang tepat untuk seseorang yang hanya melakukan hal-hal untuk bersenang-senang.

Dalam solusi yang diusulkan Anda menyebutkan bahwa minimal tiga parameter akan diperlukan:

• apikey - diberikan kepada pengembang saat pendaftaran
• timestamp - berfungsi sebagai pengidentifikasi unik untuk setiap pesan untuk apikey yang diberikan
• hash - hash cap waktu + apisecret

Implikasinya adalah bahwa untuk beberapa panggilan API tidak diperlukan nama pengguna / kata sandi. Ini dapat berguna untuk aplikasi di mana Anda tidak ingin memaksakan login (misalnya, menelusuri di toko online).

Ini adalah masalah yang sedikit berbeda dengan otentikasi pengguna dan lebih seperti otentikasi atau pengesahan perangkat lunak. Tidak ada pengguna, tetapi Anda masih ingin memastikan bahwa tidak ada akses jahat ke API Anda. Jadi, Anda menggunakan rahasia API Anda untuk menandatangani lalu lintas dan mengidentifikasi kode yang mengakses API sebagai asli. Masalah potensial dengan solusi ini adalah bahwa Anda kemudian harus memberikan rahasia di dalam setiap versi aplikasi. Jika seseorang dapat mengekstrak rahasia mereka dapat menggunakan API Anda, menyamar sebagai perangkat lunak Anda tetapi melakukan apa pun yang mereka suka.

Untuk mengatasi ancaman itu ada banyak hal yang dapat Anda lakukan tergantung pada seberapa berharganya data tersebut. Kebingungan adalah cara sederhana untuk membuatnya lebih sulit untuk mengekstrak rahasianya. Ada alat yang akan melakukannya untuk Anda, lebih untuk Android, tetapi Anda masih harus memiliki kode yang menghasilkan hash Anda dan individu yang cukup terampil selalu dapat memanggil fungsi yang melakukan hashing secara langsung.

Cara lain untuk mengurangi penggunaan berlebihan API yang tidak memerlukan login adalah dengan membatasi lalu lintas dan berpotensi mengidentifikasi dan memblokir alamat IP yang dicurigai. Jumlah upaya yang ingin Anda lakukan akan sangat tergantung pada seberapa berharga data Anda.

Di luar itu, Anda dapat dengan mudah mulai masuk ke domain pekerjaan harian saya. Bagaimanapun, ini adalah aspek lain dari pengamanan API yang menurut saya penting dan ingin ditandai.