Projekt API: podstawowe uwierzytelnianie HTTP vs Token API

Obecnie tworzę System Uwierzytelniania przed publicznym API web dla aplikacji internetowej. Biorąc pod uwagę, że każde konto użytkownika ma klucz API i każde żądanie musi być uwierzytelnione, mam dwie alternatywy:

  1. Używając podstawowego uwierzytelniania HTTP, tak jak robi to GitHub .

    Żądania należy wysyłać na adres URL 

    http://api.example.com/resource/id
with basic authentication
username: token
password: the api key

  2. Podanie Tokena API jako parametru querystring.

    Wnioski należy przesyłać na adres URL 

    http://api.example.com/resource/id?token=api_key

Jest też trzecia opcja, która przekazuje token w URI, ale szczerze mówiąc nie podoba mi się to rozwiązanie.

Jakie rozwiązanie byś przyjął i dlaczego?

Author: Simone Carletti, 2011-02-11
Source

4 answers

Myślę, że HTTP Basic Auth powinno być OK, ale tylko dla naprawdę prostych potrzeb.

Kompletnym (i końcowym) rozwiązaniem IMHO jest implementacja dostawcy OAuth. To nie jest skomplikowane, to prosty protokół i daje wiele elastyczności. Ponadto wydaje się, że jest to obecny trend, ponieważ wielu dużych graczy wdraża go i jest obsługiwany z wielu wielu bibliotek.

 12
Author: Diego Giorgini,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2016-10-19 12:32:05

Najlepszym rozwiązaniem może być użycie klucza API w nagłówku (np. 'Authorization: Token MY_API_KEY') zamiast jako url param:

Zalety w stosunku do HTTP Basic Auth:

  • wygodniejsze, ponieważ można łatwo wygasnąć lub zregenerować tokeny bez wpływu na hasło do konta użytkownika.
  • W przypadku zagrożenia Luka ogranicza się do API, a nie do konta głównego użytkownika
  • możesz mieć kilka kluczy na konto (np. użytkownicy mogą mieć klucze" testowe "i" produkcyjne " obok siebie bok.)

Zalety klucza API w URL:

  • zapewnia dodatkowy środek bezpieczeństwa, uniemożliwiając użytkownikom nieumyślne udostępnianie adresów URL z osadzonymi w nich poświadczeniami. (Również URL może skończyć się w rzeczach takich jak dzienniki serwera)
 29
Author: Yarin,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2013-12-24 02:33:47

Wiele razy musiałem myśleć o tym, jak uwierzytelniać użytkowników/żądania na API i po porównaniu większej liczby rozwiązań skończyło się na użyciu rozwiązania Amazona , gdzie nie potrzebuję lub nie mogę używać OAuth. Rozwiązanie to opiera się na podpisach, które zapobiegają problemom "man in the middle", ponieważ podstawowe Auth i przekazanie prostego tokena wysyłają dane tekstowe. Tak, możesz dodać ssl, ale to zwiększy złożoność systemu...

 17
Author: dlondero,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2011-11-23 15:12:13

Wolałbym użyć rozwiązania tokenowego. Jeśli nie masz rzeczywistych użytkowników z własną nazwą użytkownika i hasłem, to wydaje się, że używasz podstawowej konstrukcji Auth Nie zgodnie z przeznaczeniem. Nie, żeby to koniecznie było złe, ale nie tak czyste, IMO. Usuwa również potrzebę używania niestandardowych nagłówków i myślę, że sprawia, że implementacja po obu stronach jest łatwiejsza i czystsza. Kolejne pytanie, które chciałbym zadać, to czy powinieneś używać uwierzytelniania dwuskładnikowego lub czy musisz zarządzać sesjami w wszystkie.

 1
Author: Christopher Martin,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2012-10-10 19:34:23