Please enable JavaScript.

Coggle requires JavaScript to display documents.

способы аутентификации (способы (по ключам доступа (суть (Использование…

- - - - Basic — наиболее простая схема, при которой username и password пользователя передаются в заголовке Authorization в незашифрованном виде (base64-encoded). Однако при использовании HTTPS (HTTP over SSL) протокола, является относительно безопасной.
      - Digest — challenge-response-схема, при которой сервер посылает уникальное значение nonce, а браузер передает MD5 хэш пароля пользователя, вычисленный с использованием указанного nonce
      - NTLM (известная как Windows authentication) — также основана на challenge-response подходе, при котором пароль не передается в чистом виде.
      - Negotiate
  - - - Аппаратные или программные токены, которые могут генерировать одноразовые пароли на основании секретного ключа, введенного в них, и текущего времени. Секретные ключи пользователей, являющиеся фактором владения, также хранятся на сервере, что позволяет выполнить проверку введенных одноразовых паролей.
        
        Аппаратный токен RSA SecurID генерирует новый код каждые 30 секунд.
      - Случайно генерируемые коды, передаваемые пользователю через SMS или другой канал связи. В этой ситуации фактор владения — телефон пользователя (точнее — SIM-карта, привязанная к определенному номеру).
      - Распечатка или scratch card со списком заранее сформированных одноразовых паролей. Для каждого нового входа в систему требуется ввести новый одноразовый пароль с указанным номером.
  - - - Использование ключей позволяет избежать передачи пароля пользователя сторонним приложениям (в примере выше пользователь сохранил в веб-приложении не свой пароль, а ключ доступа).
      - Ключи обладают значительно большей энтропией по сравнению с паролями, поэтому их практически невозможно подобрать.
      - Кроме того, если ключ был раскрыт, это не приводит к компрометации основной учетной записи пользователя — достаточно лишь аннулировать этот ключ и создать новый.
    - - ключи могут передаваться в разных частях HTTP-запроса: URL query, request body или HTTP header
      - В некоторых случаях используют HTTP-схему Bearer для передачи токена в заголовке (Authorization: Bearer [token]). (Bearer - податель)
      - Чтобы избежать перехвата ключей, соединение с сервером должно быть обязательно защищено протоколом SSL/TLS.
  - - - Типичный пример этого способа — вход в приложение через учетную запись в социальных сетях. Здесь социальные сети являются сервисами аутентификации, а приложение доверяет функцию аутентификации пользователей социальным сетям.
    - - как
        
        Клиент просит identity provider предоставить ему токен для конкретного SP-приложения. Identity provider генерирует токен и отправляет его клиенту.
        
        Клиент аутентифицируется в SP-приложении при помощи этого токена.
        
        а оно проверяет:
        
        Токен был выдан доверенным identity provider приложением (проверка поля issuer)
        
        Токен предназначается текущему SP-приложению (проверка поля audience).
        
        Срок действия токена еще не истек (проверка поля expiration date).
        
        Токен подлинный и не был изменен (проверка подписи).
        
        Клиент аутентифицируется в identity provider одним из способов, специфичным для него (пароль, ключ доступа, сертификат, Kerberos, итд.).
    - - как
    - - OAuth
        
        OAuth — открытый протокол авторизации, который позволяет предоставить третьей стороне ограниченный доступ к защищённым ресурсам пользователя без необходимости передавать ей (третьей стороне) логин и пароль[1][2].
        
        Работа над протоколом началась в ноябре 2006 года, а последняя версия OAuth 1.0 была утверждена 4 декабря 2007 года. Как последующее развитие в 2010 году появился протокол OAuth 2.0, последняя версия которого в качестве в RFC 6749 опубликована в октябре 2012 года.
      - OpenID Connect
      - SAML
        
        Стандарт Security Assertion Markup Language (SAML) описывает способы взаимодействия и протоколы между identity provider и service provider для обмена данными аутентификации и авторизации посредством токенов
      - WS-Federation
        
        WS-Trust и WS-Federation входят в группу стандартов WS-*, описывающих SOAP/XML-веб сервисы.
    - - Сам токен обычно представляет собой структуру данных, которая содержит информацию, кто сгенерировал токен, кто может быть получателем токена, срок действия, набор сведений о самом пользователе (claims). Кроме того, токен дополнительно подписывается для предотвращения несанкционированных изменений и гарантий подлинности.
        #
      - форматы:
        
        Simple Web Token (SWT) — наиболее простой формат, представляющий собой набор произвольных пар имя/значение в формате кодирования HTML form
        
        Issuer=http://auth.myservice.com&
        Audience=http://myservice.com&
        ExpiresOn=1435937883&
        UserName=John Smith&
        UserRole=Admin&
        HMACSHA256=KOUQRPSpy64rvT2KnYyQKtFFXUIggnesSpE7ADA4o9w
        
        JSON Web Token (JWT) — содержит три блока, разделенных точками: заголовок, набор полей (claims) и подпись.
        
        { «alg»: «HS256», «typ»: «JWT» }.
        { «iss»: «auth.myservice.com», «aud»: «myservice.com», «exp»: «1435937883», «userName»: «John Smith», «userRole»: «Admin» }.
        S9Zs/8/uEGGTVVtLggFTizCsMtwOJnRhjaQ2BMUQhcY
        
        Security Assertion Markup Language (SAML) — определяет токены (SAML assertions) в XML-формате, включающем информацию об эмитенте, о субъекте, необходимые условия для проверки токена, набор дополнительных утверждений (statements) о пользователе.