Использование токена-носителя для аутентификации (≠ авторизация)

Запрос на использование Authorization: bearer [token] может использоваться для аутентификации?

или

Следует ли использовать другой метод аутентификации клиента и выдавать токен, а затем использовать токен в качестве маркера-носителя, например, OAuth2? Почему популярные веб-службы (например, Github, AWS, Google..) используют другой метод (например, AWS: Authorization: AWS4-HMAC-SHA256 Credential=...) для аутентификации клиента. Вопрос заключается в следующем: есть ли какие-либо ценности или нарушение стандартов в следующем потоке или нет.

Я хотел бы использовать следующий поток:

the client: это как клиент Twitter.
the server: это похоже на API Twitter.

клиент делает маркер (зашифрованный идентификатор пользователя, пароль и т.д.).
клиент запрашивает ресурс на сервере с помощью Authorization: bearer [token].
сервер расшифровывает токен и аутентифицирует клиента.
сервер отвечает за ресурс.

Я читал следующий RFC, но я не нашел причин, почему я не должен или должен использовать поток выше.

https://tools.ietf.org/html/rfc7235
https://tools.ietf.org/html/rfc6750

Спасибо

Ответ 1

Я бы рекомендовал придерживаться спецификации OAuth2. Если вы хотите использовать имя пользователя и пароль для получения токена, вы должны использовать поток "Client Credentials". Это означает, что вам нужна конечная точка "https", где пользователь может получить токен доступа через следующий запрос POST:

POST /token HTTP/1.1
Authorization: Basic base64_encode("username:password")
Content-Type: application/x-www-form-urlencoded

grant_type=client_credentials

Если учетные данные клиента действительны, конечная точка должна создать токен доступа на сервере. Помимо токена, вы должны сохранить, кто получил токен и временную метку, когда истекает токен. Таким образом, токен не должен быть именем пользователя и паролем, зашифрованным как в вашем примере, а должен быть случайной строкой, которая назначена пользователю.

Затем токен доступа может использоваться клиентом для доступа к защищенным частям вашего API. Если ваш API получает токен-носитель, вы можете найти назначенного пользователя в своей таблице токенов.

Как говорится в OAuth2, вы обычно получаете токен доступа, хотя ключ и секрет приложения, которые вы получили ранее поставщиком API. Это имеет то преимущество, что пользователю не нужно делиться учетными данными с сторонним приложением. Но зависит ли это от вашего использования.

Ответ 2

Почему популярные веб-службы (например, Github, AWS, Google..) используют другой метод (например, AWS: Авторизация: AWS4-HMAC-SHA256 Credential =...) для аутентификации клиента.

Заголовок подписки AWS не основан только на учетных данных клиента, он также включает в себя биты, полученные из самого запроса, а также текущее время. Чистым эффектом является то, что проверяется не только идентификация клиента, но и содержимое запроса, поэтому кто-то не сможет использовать подпись по другому запросу (или изменить запрос в полете), даже если им удалось каким-то образом получить подпись, Включение текущего времени делает подпись действительной только в течение ограниченного периода времени, уменьшая повторные атаки.

Ответ 3

Маркер-носитель с сервера OAuth2 не должен использоваться в качестве прямого средства аутентификации. Они не представляют конечного пользователя, но вместо этого запрашивают авторизацию, которую клиент должен действовать от имени этого пользователя. Их статья ясно объясняет, почему.

Если вы хотите реализовать собственный сервер Othentication, вы можете использовать OpenID Connect. Это стандарт, построенный поверх OAuth 2.0. OIDC использует токен-носитель таким образом, чтобы обеспечить аутентификацию.

У них есть список сертифицированных библиотек, которые можно использовать для реализации вашего сервера. Или вы можете использовать один из MANY предустановить поставщиков IODC