2NetFly
-
Те, кто не используют OAuth, изобретают велосипед, две одинаковые схемы аутентификации в разных проектах найти очень сложно. Предлагаю обсудить наиболее распространенные варианты, их достоинства и недостатки.
Стандарт безопасности, применимый к нашей системе, требует двухфакторной аутентификации т.ч. мы используем клиентские сертификаты с паролем плюс подпись запроса секретным ключом (передача в заголовке Authorization), все это дело по SSL.
Если жестких требований к системе не предъявляется, оптимальной лично мне видится схема с обычной базовой аутентификацией, естественно, по SSL. Из преимуществ:
- простота реализации как на сервере, так и на клиенте;
- отсутствие лишней информации в URI;
- возможность использовать в качестве клиента браузер (в целях дебага, самодокументирования и т.д.).
Если пользователю предоставляется доступ и к API и к обычному интерфейсу, разумно создавать отдельные учетные записи. С другой стороны, если набор доступных действий через API идентичный таковому через интерфейс, особого смысла в этом нет.
Стандарт безопасности, применимый к нашей системе, требует двухфакторной аутентификации т.ч. мы используем клиентские сертификаты с паролем плюс подпись запроса секретным ключом (передача в заголовке Authorization), все это дело по SSL.
Если жестких требований к системе не предъявляется, оптимальной лично мне видится схема с обычной базовой аутентификацией, естественно, по SSL. Из преимуществ:
- простота реализации как на сервере, так и на клиенте;
- отсутствие лишней информации в URI;
- возможность использовать в качестве клиента браузер (в целях дебага, самодокументирования и т.д.).
Если пользователю предоставляется доступ и к API и к обычному интерфейсу, разумно создавать отдельные учетные записи. С другой стороны, если набор доступных действий через API идентичный таковому через интерфейс, особого смысла в этом нет.