Как защищен oauth при использовании с REST API
У меня есть веб-приложение, которое взаимодействует с моим REST api. Я решил использовать аутентификацию oauth, и я выполнил несколько руководств о том, как ее реализовать, но я все еще пытаюсь понять, почему это безопасно или как я могу сделать это безопасным.
Моя реализация выглядит примерно так ...
1. client makes request to Facebook
2. client clicks `allow access`
3. Facebook redirects back to client with code in URL
4. client makes a POST request of the code to the REST API
5. REST API authenticates code via a request to Facebook using the secret key
6. Success/fail response to client from REST API
Моя проблема в том, как это обеспечить безопасность? Насколько я могу судить, код сохраняется в URL-адресе браузера, поэтому какой-то вредоносный код может извлечь этот код. Если вредоносный код может выяснить, какой вызов REST аутентифицирует код до истечения срока его действия, они могут затем аутентифицировать себя как кто-то еще и получить доступ к своим данным.
Возможно, что моя реализация неверна, однако я следил за этим диаграмма, как мог, а также за другими руководствами.
Если мой подход неверен, что я могу сделать для обеспечения безопасности?
Ответы 1
Я перейду к вашему вопросу через мгновение, но сначала позвольте мне сказать несколько предварительных сведений.
Oauth касается авторизации, а не аутентификации. Измените «аутентифицировать» на «авторизовать» в своем вопросе.
«Разрешить доступ» нажимает не клиент, а пользователь. Суть Oauth заключается в том, что пользователь хочет предоставить клиенту доступ к некоторым своим данным, не сообщая клиенту свой пароль. Oauth позволяет ему делать это с помощью доверенного браузера, поэтому пользователь может чувствовать себя в безопасности при использовании клиента.
Без протокола Ouath единственный способ, которым он мог бы это сделать, - это предоставить свой пароль клиенту. Представьте, что множество клиентов, которых вы используете каждый день, хотят получить доступ к вашим данным Facebook - без Oauth вам пришлось бы вводить свои учетные данные Facebook в этих клиентов, что дало бы им полный доступ ко всему вашему Facebook. Вы бы чувствовали себя комфортно с этим? Вы не должны, потому что это откроет дверь для всех видов злоупотреблений вредоносным ПО. Oauth позволяет ограничить доступ этих клиентов к вашей учетной записи Facebook (или другой учетной записи), чтобы вы могли быть уверены в используемом приложении.
Теперь к вашему вопросу - риск кода в URL. Это действительно серьезная проблема, но она предназначена для одноразового использования (он обменивается на токен доступа для использования с множественным доступом) и имеет короткий срок службы. Причина, по которой используется код авторизации, объясняется в Раздел 3.4 модели угроз Oauth. Точная проблема, о которой вы спрашиваете, рассматривается в Раздел 4.4.1.1 модели угроз Oauth:
o As per the core OAuth spec, the authorization server as well as the client must ensure that these transmissions are protected using transport-layer mechanisms such as TLS (see Section 5.1.1).
o The authorization server will require the client to authenticate wherever possible, so the binding of the authorization "code" to a certain client can be validated in a reliable way (see Section 5.2.4.4).
o Use short expiry time for authorization "codes" (Section 5.1.5.3).
o The authorization server should enforce a one-time usage restriction (see Section 5.1.5.4).
o If an authorization server observes multiple attempts to redeem an authorization "code", the authorization server may want to revoke all tokens granted based on the authorization "code" (see Section 5.2.1.1).
o In the absence of these countermeasures, reducing scope (Section 5.1.5.1) and expiry time (Section 5.1.5.3) for access tokens can be used to reduce the damage in case of leaks.
o The client server may reload the target page of the redirect URI in order to automatically clean up the browser cache.
Теперь также есть усовершенствование протокола Oauth, опубликованного в RFC 7636, которое защищает от кражи кода авторизации для конкретного клиента на мобильном устройстве другими клиентами. См. RFC для более подробной информации.
Спасибо, это было невероятно подробно и очень мне помогло!