REST API Authentication

181

Saya sedang membangun aplikasi yang akan di-host di server. Saya ingin membuat API untuk aplikasi untuk memfasilitasi interaksi dengan dari platform apa pun (Aplikasi Web, Aplikasi Seluler). Yang tidak saya mengerti adalah bahwa ketika menggunakan REST API, bagaimana kami mengautentikasi pengguna.

Misalnya, ketika pengguna telah masuk dan kemudian ingin membuat topik forum. Bagaimana saya tahu bahwa pengguna sudah masuk?

api  rest 
— Noor
sumber
4
Anda mungkin harus mencari "otentikasi REST" di sini. Sudah dibahas dalam banyak pertanyaan lain.
— Brian Kelly
10
Singkatnya, biarkan klien mengirim nama pengguna dan kata sandi dengan setiap permintaan menggunakan HTTP Basic Auth (lebih dari SSL!), Atau mengautentikasi sekali sehingga klien memiliki sesi yang diautentikasi yang akan kedaluwarsa setelah beberapa periode tidak aktif (atau bagaimanapun Anda memilih untuk mengganti penanganan sesi kerangka kerja web Anda). Sesi yang disebutkan kemudian dapat disimpan dalam cookie, atau menjadi parameter yang diteruskan dengan setiap permintaan (misalnya JSESSIONID di tanah Jawa).
— Opyate
— Arjan
@ copyate dari sudut pandang keamanan, itu bukan ide yang baik untuk memiliki sesi ditangani menggunakan cookie dalam kasus REST API, karena penyerang dapat mengirim permintaan tanpa persetujuan pengguna. Lebih baik untuk memasukkan hash atau token sesi dalam header HTTP (seperti Otorisasi).
— s3v3n
1
@ s3v3n Perbaiki saya jika saya salah, tetapi saran Anda dan saya hanyalah cara berbeda menggunakan header + kombo penyimpanan lokal untuk menghasilkan hal yang sama. Itu Authorizationheader + misalnya browser localStorage VS Cookieheader + penyimpanan cookie browser standar.
— Opyate

Jawaban:

72

Anda dapat menggunakan HTTP Basic atau Otentikasi Intisari. Anda dapat mengautentikasi pengguna yang menggunakan SSL secara aman di atasnya, namun, itu sedikit memperlambat API.

  • Otentikasi dasar - menggunakan pengkodean Base64 pada nama pengguna dan kata sandi
  • Intisari intisari - hash nama pengguna dan kata sandi sebelum mengirimnya melalui jaringan.

OAuth adalah yang terbaik yang bisa didapat. Keuntungan yang diberikan oAuth adalah token yang dapat dicabut atau diharapkan. Rujuk mengikuti cara penerapan: Tautan yang Berfungsi dari komentar: https://www.ida.liu.se/~TDP024/labs/hmacarticle.pdf

— ankitjaininfo
sumber
4
Silakan baca pertanyaan ini dan jawaban yang diberikan oleh Les Hazelwood (penulis Apache Shiro).
— justin.hughey
1
Tautan bermanfaat bagaimana Twitter melindunginya REST API: Twitter REST API Security
— WildDev
Karena ini adalah jawaban yang diterima, saya merasa penting untuk menyebutkan bahwa Anda juga dapat menggunakan otentikasi Digest. Baca tentang perbedaan antara otentikasi Dasar dan Intisari di sini: stackoverflow.com/questions/9534602/…
— Rayee Roded
116

Misalnya, ketika pengguna login. Sekarang katakanlah pengguna ingin membuat topik forum, Bagaimana saya tahu bahwa pengguna sudah masuk?

Pikirkan tentang hal itu - harus ada jabat tangan yang memberi tahu Anda tentang "Buat Forum" API bahwa permintaan saat ini dari pengguna yang diautentikasi. Karena REST API biasanya tidak memiliki kewarganegaraan, negara harus bertahan di suatu tempat . Klien Anda yang mengonsumsi API REST bertanggung jawab untuk mempertahankan status itu. Biasanya, itu dalam bentuk beberapa token yang akan diteruskan sejak saat pengguna login. Jika token itu baik, permintaan Anda baik.

Periksa bagaimana Amazon AWS melakukan otentikasi. Itu adalah contoh sempurna dari "meneruskan tanggung jawab" dari satu API ke API lainnya.

* Saya berpikir untuk menambahkan beberapa jawaban praktis untuk jawaban saya sebelumnya. Coba Apache Shiro (atau perpustakaan otentikasi / otorisasi). Intinya, coba dan hindari pengkodean khusus. Setelah Anda mengintegrasikan perpustakaan favorit Anda (saya menggunakan Apache Shiro, btw) Anda kemudian dapat melakukan hal berikut:

  1. Buat API Login / logout seperti: /api/v1/logindanapi/v1/logout
  2. Di API Masuk dan Keluar ini, lakukan otentikasi dengan toko pengguna Anda
  3. Hasilnya adalah token (biasanya, JSESSIONID) yang dikirim kembali ke klien (web, seluler, apa pun)
  4. Dari titik ini dan seterusnya, semua panggilan selanjutnya yang dilakukan oleh klien Anda akan menyertakan token ini
  5. Katakanlah panggilan Anda berikutnya dilakukan ke API yang disebut /api/v1/findUser
  6. Hal pertama yang akan dilakukan kode API ini adalah memeriksa token ("apakah pengguna ini diautentikasi?")
  7. Jika jawabannya kembali sebagai TIDAK, maka Anda melemparkan Status HTTP 401 kembali ke klien. Biarkan mereka menanganinya.
  8. Jika jawabannya YA, maka lanjutkan untuk mengembalikan Pengguna yang diminta

Itu saja. Semoga ini membantu.

— Kingz
sumber
Jadi apa yang Anda gambarkan pada dasarnya adalah cookie sesi, bukan?
— LordOfThePigs
ya, tetapi sesi "dipertahankan" di 2 tempat berbeda. Satu di server API, yang lain di Browser. Respons JSON (atau apa pun) kembali ke posting browser setelah login berhasil harus mengkomunikasikan id sesi pada server API kembali ke browser. Sesi ini dikelola secara independen oleh agen masing-masing.
— Kingz
11
Saya percaya Kingz sedang mencoba untuk menanamkan gagasan bahwa mekanisme untuk mempertahankan sesi sengaja tidak jelas. Cookie sesi hanyalah salah satu implementasi dari mekanisme itu.
— justin.hughey
2
@ Kingz, Bagaimana dengan keamanan dalam solusi ini, misalnya jika ada peretas mengendus tautan dengan session_id dan mulai mengirim permintaan konten mana yang benar, session_id? Kita dapat menyelesaikannya dengan menambahkan ssl ke koneksi server, tetapi bagaimana dengan klien?
— Ahmad Samilo
1
bagaimana mencegah pembajakan sesi dalam kasus man-in-the-middle-attrack?
— m0z4rt
38

  1. Gunakan HTTP Basic Auth untuk mengotentikasi klien, tetapi perlakukan nama pengguna / kata sandi hanya sebagai token sesi sementara .

    Token sesi hanyalah tajuk yang dilampirkan pada setiap permintaan HTTP, misalnya: Authorization: Basic Ym9ic2Vzc2lvbjE6czNjcmV0

    String Ym9ic2Vzc2lvbjE6czNjcmV0 di atas hanyalah string "bobsession1: s3cret" (yang merupakan nama pengguna / kata sandi) yang disandikan di Base64.

  2. Untuk mendapatkan token sesi sementara di atas, berikan fungsi API (misalnya:) http://mycompany.com/apiv1/loginyang mengambil master-username dan master-password sebagai input, membuat sementara HTTP Basic Auth username / password di sisi server, dan mengembalikan token (misalnya: Ym9ic2Vzc2lvbjE6czNjcmV0). Nama pengguna / kata sandi ini harus sementara, harus berakhir setelah 20 menit atau lebih.

  3. Untuk keamanan tambahan, pastikan layanan REST Anda dilayani melalui HTTPS sehingga informasi tidak ditransfer plaintext

Jika Anda menggunakan Java, pustaka Spring Security menyediakan dukungan yang baik untuk mengimplementasikan metode di atas

— gerrytan
sumber
1
Mengapa harus kedaluwarsa setelah 20 menit? bagaimana jika itu adalah situs web seperti facebook yang login sampai pengguna keluar?
— Dejell
1
@ Djel saya di bawah asumsi "sesi" bersifat sementara. Adalah umum untuk kedaluwarsa jika pengguna idling
— gerrytan
Untuk apa Base64? Anda bisa mengembalikan kata sandi sementara. Dalam kedua kasus tersebut, yang terpenting adalah kata sandi sementara ini kuat. Periksa security.stackexchange.com/a/19686/72945
— e18r
7

Saya pikir pendekatan terbaik adalah menggunakan OAuth2. Google dan Anda akan menemukan banyak posting berguna untuk membantu Anda mengaturnya.

Akan lebih mudah untuk mengembangkan aplikasi klien untuk API Anda dari aplikasi web atau aplikasi seluler.

Semoga ini bisa membantu Anda.

— Paulo Henrique
sumber
2
Silakan baca pertanyaan ini dan jawabannya oleh Les Hazelwood (penulis Apache Shiro).
— justin.hughey
0

Saya telah menggunakan otentikasi JWT. Bekerja dengan baik di aplikasi saya.

Ada metode otentikasi yang akan memerlukan kredensial pengguna. Metode ini memvalidasi kredensial dan mengembalikan token akses jika sukses.

Token ini harus dikirim ke setiap metode lain di API Web saya di header permintaan.

Ini sangat mudah diimplementasikan, dan sangat mudah untuk diuji.

— Arthur Medeiros
sumber
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.