Дайджест, базовая аутентификация и аутентификация на предъявителя

Question

Недавно я опубликовал проблему У меня была проблема с аутентификацией, но я не получил никаких ответов, поэтому я подумал о другом способе задать вопрос, не будучи лишним.

То, что я вижу в приложениях Документация - это три способа передачи токена доступа для аутентификации и получения информации, которую я пытаюсь получить: HTTP Дайджест auth, HTTP Basic auth и Bearer toh auth. Различия между ними неясны для меня, и мои попытки аутентификация токена на предъявителя (см. ШАГ 5) не сработали.

Может кто-нибудь объяснить, что это за трое и, надеюсь, указать, что я делаю неправильно?

Answer 1

«Базовая аутентификация HTTP» и «Дайджест HTTP» аутентифицируются с использованием имени пользователя и секрета.Аутентификация дайджеста HTTP более безопасна, поскольку она не отправляет имя пользователя и секрет в виде обычного текста.

«Аутентификация HTTP-носителя» с использованием access_token.

Ваш код аутентификации HTTP-носителя выглядит хорошо для меня,

Answer 2

Между базовой аутентификацией HTTP и дайджест-аутентификацией HTTP нет большой разницы.

Для базовой аутентификации До запроса с именем пользователя системы oAuth добавляется двоеточие и соединяется с паролем.Затем результат будет закодирован с помощью алгоритма Base64.

Например, скажем, username равно demo, а ваше access_token равно 123, поэтому в этом случае результирующая строка после объединения будет 'demo:123'и как только мы применим кодирование Base64, оно станет ZGVtbzoxMjM=

Теперь эта кодированная строка передается в HTTP header и декодируется провайдером oAuth. Опять же, это не очень сильный механизм кодирования, и его легко можнодекодированный как эта система проверки подлинности, не предназначен для системы с очень высокой степенью защиты.

Опять же, Digest также использует протокол HTTP для отправки и получения данных, но он намного лучше, чем базовый OAuth, который отправляет данные в plaintext .Digest используетMD5 cryptographic hashing тип алгоритма для шифрования вашего password/access_token и помимо этого он использует значение nonce, чтобы остановить атаку воспроизведения.

Надеюсь, что это даст вам некоторое представление о том, как они работают.

Обновление

Я только что видел код на панели Gimme

GET /api/v0/tags HTTP/1.1
Host: gimmebar.com
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_6_7; en-us) AppleWebKit/533.6+ (KHTML, like Gecko) Version/4.0 Safari/528.16 Titanium/1.1.0
Accept: */*
Accept-Language: en-us
Accept-Encoding: gzip, deflate
Authorization: Digest username="funkatron", realm="GimmeBarAPI", nonce="7a3ab1f9cde605f27797cd04c4d1fcf6", uri="/api/v0/tags", response="3654f9b1b2ba9489e1f01ae792852987", opaque="94619f8a70068b2591c2eed622525b0e", algorithm="MD5", cnonce="6897ccbff3b08776ab61e69a814c05b4", nc=00000001, qop="auth"
Connection: keep-alive

, и если вы видите, что при отправке запроса они проходят алгоритм хеширования used вместе с nonce, username. Итак, все они создают их в своем приложении и размещают в разделе заголовка. Все, что вам нужно найти, какое имя заголовка нам нужно поставить.

Answer 3

Маркер-носитель генерируется на стороне сервера, когда вы аутентифицируетесь на сервере.Затем для каждого последующего запроса вы указываете сгенерированный токен на предъявителя в заголовке запроса.

С точки зрения безопасности эти токены генерируются с использованием закрытого ключа, только сервер, аутентифицирующий пользователя, знает этот ключ

Посмотрите на jwt у них действительно хорошая документация по этой конкретной теме

gimmebar документация довольно ясно о том, как получить доступ

POST / api / v0 / auth / reqtoken HTTP / 1.1

Ответное сообщение

{"request_token": "390a9b193fc51be1a78d13bf69555212", "expires": 1309375411}