Kubofonista we wpisie na blogu wyróżnił trzy możliwe sposoby autoryzacji: “Login i Hasło”, ApiKey i OAuth który uznał za najlepszą metodę, z czym ja się nie zgodzę. Plusem OAuth jest oczywiście to, że aplikacja nie zna hasła użytkownika do danego serwisu, możliwość zarządzania autoryzowanymi aplikacjami oraz cofania dostępu do konta w danym serwisie. Podstawowym problemem jest niemożność zastosowania OAuth w przypadku aplikacji desktopowych oraz o otwartym kodzie (np. JavaScript). W tym przypadku rozwiązaniem jest stosowanie w dalszym ciągu ApiKey lub “Loginu i Hasła”.

W związku z krytyką aktualnego sposobu autoryzacji zacząłem się zastanawiać nad innymi sposobami i wpadłem na pomysł który nazwałem przyjaźnie dla użytkownika: “Hasła dla aplikacji”, podobnie jak to opiszę opisał to we wspomnianym wpisie Kubofonista.

“Hasła dla aplikacji” jest to połączenie wszystkich trzech wspomnianych wcześniej sposobów autoryzacji, a więc wyobrażam sobie to tak: po zalogowaniu, w menu obok linków do kokpitu, Bliposfey itd. pojawił by się link do podstrony na której użytkownik zarządzał by swoimi “Hasłami dla aplikacji”. Na tejże podstronie znajdowała by się lista wygenerowanych haseł oraz możliwość wygenerowania nowego hasła, każde wygenerowane hasło użytkownik mógłby opisać np. “Sekretarka Tomasza Topy”. Wprowadzenie tego typu autoryzacji nie wymagało by żadnych zmian w BlipAPI, gdyż “Hasło dla aplikacji” podawało by się tam, gdzie do tej pory podawało się zwykłe hasło. Użytkownik miałby możliwość tymczasowego wyłączenia hasła, jego skasowania, oraz w dalszej perspektywie ograniczania jego możliwości (np. tylko pobieranie wiadomości) oraz przeglądania statystyk czynności wykonywanych przez aplikację, oczywiście wszystko przez stronę blipa. W przypadku próby zalogowania zwykłym hasłem, lub podanie nieistniejącego hasła serwer BlipAPI zwracał by “Unautorized”, natomiast w przypadku tymczasowego wyłączenia hasła, lub próby wykonania niedozwolonej czynności określone w dokumentacji błędy.

Osobną kwestią pozostaje bezpieczeństwo przesyłanych danych, tutaj dałbym programistą dwie możliwości, albo połączenie https, albo opublikowanie klucza publicznego w dokumentacji API, ale ogólnie szyfrowanie to nie temat tego wpisu. Poza tym całe API wymaga poprawek w obsłudze aplikacji JavaScript.

Podsumowując, co się pewnie nie wszystkim spodoba jestem i raczej będę przeciwnikiem wprowadzania OAuth do jakichkolwiek projektów.

Na zakończenie dodam coś w co nie wszyscy uwierzą, że wpadając na pomysł “Haseł do aplikacji” nie wiedziałem, że Kubofonista już coś takiego opisał ;) .