HTTP Dasar dan Autentikasi Token Pembawa

Saat ini saya sedang mengembangkan REST-API yang dilindungi HTTP-Basic untuk lingkungan pengembangan. Karena autentikasi sebenarnya dilakukan melalui token, saya masih mencoba mencari tahu, bagaimana cara mengirim dua header otorisasi.

Saya sudah mencoba yang ini:

curl -i http://dev.myapp.com/api/users \
  -H "Authorization: Basic Ym9zY236Ym9zY28=" \
  -H "Authorization: Bearer mytoken123"

Misalnya, saya dapat menonaktifkan Autentikasi HTTP untuk IP saya, tetapi karena saya biasanya bekerja di lingkungan yang berbeda dengan IP dinamis, ini bukan solusi yang baik. Jadi, apakah saya melewatkan sesuatu?

Coba yang ini untuk mendorong otentikasi dasar di url:

curl -i http://username:password@dev.myapp.com/api/users -H "Authorization: Bearer mytoken123"
               ^^^^^^^^^^^^^^^^^^

Jika di atas tidak berhasil, maka Anda tidak ada hubungannya dengan itu. Jadi coba alternatif berikut.

Anda dapat memberikan token dengan nama lain. Karena Anda menangani otorisasi dari Aplikasi Anda. Jadi, Anda dapat dengan mudah menggunakan fleksibilitas ini untuk tujuan khusus ini.

curl -i http://dev.myapp.com/api/users \
  -H "Authorization: Basic Ym9zY236Ym9zY28=" \
  -H "Application-Authorization: mytoken123"

Perhatikan bahwa saya telah mengubah header menjadi Application-Authorization. Jadi dari aplikasi Anda, tangkap token di bawah tajuk itu dan proses apa yang perlu Anda lakukan.

Hal lain yang dapat Anda lakukan adalah, untuk lulus tokenmelalui POSTparameter dan ambil nilai parameter dari sisi Server. Misalnya meneruskan token dengan parameter curl post:

-d "auth-token=mytoken123"

Standar ( https://tools.ietf.org/html/rfc6750 ) mengatakan Anda dapat menggunakan:

• Parameter Badan yang Dikodekan Formulir: Otorisasi: Bearer mytoken123
• Parameter Kueri URI: access_token = mytoken123

Jadi dimungkinkan untuk meneruskan banyak Token Pembawa dengan URI, tetapi melakukan ini tidak disarankan (lihat bagian 5 dalam standar).

Jika Anda menggunakan proxy terbalik seperti nginx di antaranya, Anda dapat menentukan token khusus, seperti X-API-Token .

Di nginx Anda akan menulis ulang untuk upstream proxy (rest api Anda) menjadi hanya auth:

proxy_set_header Authorization $http_x_api_token;

... sementara nginx dapat menggunakan header Otorisasi asli untuk memeriksa HTTP AUth.

Saya mengalami masalah yang sama - mengautentikasi perangkat dan pengguna di perangkat. Saya menggunakan Cookieheader di samping Authorization: Bearer...header.

curl --anyauth

Memberi tahu curl untuk mengetahui metode otentikasi dengan sendirinya, dan menggunakan yang paling aman yang diklaim oleh situs jarak jauh untuk didukung. Hal ini dilakukan dengan terlebih dahulu melakukan permintaan dan memeriksa header respons, sehingga mungkin menyebabkan jaringan tambahan pulang pergi. Ini digunakan sebagai ganti menyetel metode autentikasi tertentu, yang dapat Anda lakukan dengan --basic, --digest, --ntlm, dan --negotiate.

Ada solusi lain untuk menguji API di server pengembangan.

• Set HTTP Basic Authentication hanya untuk rute web
• Biarkan semua rute API bebas dari otentikasi

Konfigurasi server web untuk nginxdan Laravelakan seperti ini:

    location /api {
        try_files $uri $uri/ /index.php?$query_string;
    }

    location / {
        try_files $uri $uri/ /index.php?$query_string;

        auth_basic "Enter password";
        auth_basic_user_file /path/to/.htpasswd;
    }

Authorization: Bearer akan melakukan tugas untuk melindungi server pengembangan dari perayap web dan pengunjung tak diinginkan lainnya.

Dengan nginx Anda dapat mengirim kedua token seperti ini (meskipun itu bertentangan dengan standar):

Authorization: Basic basic-token,Bearer bearer-token

Ini berfungsi selama token dasar adalah yang pertama - nginx berhasil meneruskannya ke server aplikasi.

Dan kemudian Anda perlu memastikan aplikasi Anda dapat mengekstrak Bearer dengan benar dari string di atas.