Вопрос по – какой смысл обновлять токен?

29

Я должен признаться, что у меня был этот вопрос в течение очень долгого времени, я никогда не понимал.

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

какова действительная причина этого, может быть, историческая? очень хочу знать. Спасибо

спасибо, это полезно! wangii
stackoverflow.com/questions/3487991/… Anders Lindahl

Ваш Ответ

4   ответа
11

Stateless authentication without hitting the DB on each request

Предположим, вы хотите создать механизм безопасности без состояния (без сеанса), который может выполнять аутентификацию миллионов пользователей, без необходимости выполнять вызов базы данных для выполнения аутентификации. Со всем трафиком, которое получает ваше приложение, экономия на вызове БД для каждого запроса стоит много! И он должен быть без сохранения состояния, чтобы его можно было легко кластеризовать и масштабировать до сотен или даже тысяч серверов.

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

Put the user info directly in the access token

Но мы не хотим сессий. Таким образом, вместо сохранения информации пользователя в сеансе, давайте просто поместим ее в токен доступа. Мы подписываем маркер, чтобы никто не мог подделать его и сделать это. Мы можем аутентифицировать запросы без сеанса и без необходимости искать информацию пользователя из БД для каждого запроса.

No session ... no way to ban users?

Но отсутствие сессии имеет большой недостаток. Что если этот пользователь забанен, например? По старому сценарию мы просто удаляем его сеанс. Затем он должен снова войти в систему, что он не сможет сделать. Запрет завершен. Но в новом сценарии нет сессии. Так как мы можем его забанить? Мы должны были бы попросить его (очень вежливо) удалить его токен доступа. Проверять каждый входящий запрос по списку банов? Да, сработало бы, но теперь мы снова должны сделать тот вызов БД, который нам не нужен.

Compromise with short-lived tokens

Если мы считаем приемлемым, что пользователь все еще может использовать свою учетную запись, скажем, в течение 10 минут после запрета, мы можем создать ситуацию, которая является компромиссом между проверкой БД при каждом запросе и только при входе в систему. И именно здесь приходят токены обновления. Они позволяют нам использовать механизм без сохранения состояния с недолговечными токенами доступа. Мы не можем отозвать эти токены, так как для них не выполняется проверка базы данных. Мы проверяем только дату истечения срока действия по текущему времени. Но после истечения срока действия пользователю потребуется предоставить токен обновления, чтобы получить новый токен доступа. На данный момент мы проверяем БД и видим, что пользователь был забанен. Поэтому мы отклоняем запрос на токен доступа, и запрет вступает в силу.

Error: User Rate Limit Exceeded
Error: User Rate Limit Exceeded
Error: User Rate Limit Exceeded
Error: User Rate Limit Exceeded
1

Refresh tokens allow for scoped / different decay times of tokens. Актуальные токены ресурса недолговечны, в то время как токен обновления может оставаться действительным в течение многих лет (мобильные приложения). Это обеспечивает лучшую безопасность (токены ресурсов не должны быть защищены) и производительность (только API токенов обновления должен проверять достоверность в отношении БД).

35

статья на днях Таизир Джуд, и я нахожу это очень полезным, он сказал:

По моему мнению, есть три основных преимущества использования токенов обновления:

Updating access token content: as you know the access tokens are self contained tokens, they contain all the claims (Information) about the authenticated user once they are generated, now if we issue a long lived token (1 month for example) for a user named “Alex” and enrolled him in role “Users” then this information get contained on the token which the Authorization server generated. If you decided later on (2 days after he obtained the token) to add him to the “Admin” role then there is no way to update this information contained in the token generated, you need to ask him to re-authenticate him self again so the Authorization server add this information to this newly generated access token, and this not feasible on most of the cases. You might not be able to reach users who obtained long lived access tokens. So to overcome this issue we need to issue short lived access tokens (30 minutes for example) and use the refresh token to obtain new access token, once you obtain the new access token, the Authorization Server will be able to add new claim for user “Alex” which assigns him to “Admin” role once the new access token being generated

Revoking access from authenticated users: Once the user obtains long lived access token he’ll be able to access the server resources as long as his access token is not expired, there is no standard way to revoke access tokens unless the Authorization Server implements custom logic which forces you to store generated access token in database and do database checks with each request. But with refresh tokens, a system admin can revoke access by simply deleting the refresh token identifier from the database so once the system requests new access token using the deleted refresh token, the Authorization Server will reject this request because the refresh token is no longer available (we’ll come into this with more details).

No need to store or ask for username and password: Using refresh tokens allows you to ask the user for his username and password only one time once he authenticates for the first time, then Authorization Server can issue very long lived refresh token (1 year for example) and the user will stay logged in all this period unless system admin tries to revoke the refresh token. You can think of this as a way to do offline access to server resources, this can be useful if you are building an API which will be consumed by front end application where it is not feasible to keep asking for username/password frequently.

Error: User Rate Limit Exceeded
Error: User Rate Limit Exceeded
Error: User Rate Limit Exceeded
Error: User Rate Limit Exceeded
Error: User Rate Limit Exceeded wangii
11

In case of compromise, the time window it's valid for is limited, but the tokens are used over SSL, so unlikely to be compromised.

Я думаю, что важной частью является то, что маркеры доступа часто регистрируются (особенно когда они используются в качестве параметра запроса, что полезно для JSONP), поэтому для них лучше быть недолговечными.

Есть несколько дополнительных причин, с крупномасштабными реализациями OAuth 2.0 поставщиками услуг:

API servers can securely validate access tokens without DB lookups or RPC calls if it's okay to not worry about revocation. This can have strong performance benefits and lessen complexity for the API servers. Best if you're okay with a token revocation taking 30m-60m (or whatever the length of the access token is). Of course, the API servers could also keep an in-memory list of tokens revoked in the last hour too.

Since tokens can have multiple scopes with access to multiple different API services, having short-lived access tokens prevents a developer of API service for getting a lifelong access to a user's data on API service B. Compartmentalization is good for security.

Error: User Rate Limit Exceeded
Error: User Rate Limit Exceeded
Error: User Rate Limit Exceeded wangii
Error: User Rate Limit Exceeded
Error: User Rate Limit Exceeded wangii

Похожие вопросы