Смотря для чего вы их используете. Почему криво-то?
На мой взгляд, это та же cookie с сессией, только сбоку.
Но даёт сложности в виде проверки — если access_token протух, то через refresh получить новый access_token и повторить запрос. Ещё +1 обёртка над сетевыми запросами.
Ну вот сразу: куда вводит логин/пароль? В мобильное приложение?
В МП. Native наше всё. Ну, и по большому счету, имхо, нет разницы между native и браузером. Меня «радует» рекомендация PCI DSS для ввода данных банковских карт — давать вводить CC number и CVC2 в МП это не безопасно, а через webview это нормально.
Что должно произойти, если за этот месяц юзер поменял пароль?
При смене пароля можно отозвать refresh токен. А можно и не отзывать. Ведь возможность работы с функциональностью МП != от значений логина и пароля.
Т.е. все пляски из-за того, чтобы просто не ломать oauth, но при этом нарушаем РЕКОМЕНДАЦИЮ, чтобы refresh давать только server side приложениям.
Применительно к мобильным приложениям(МП) или SDK, Oauth и токены как-то криво вписываются.
Задача: юзер вводит логин и пароль, работает в МП. Через месяц юзер снова запускает МП, и продолжает работать.
В связи с тем, что Authz(Authn)(Identity)Server поддерживают только OAuth и OpenID, эту задачу я решил так: access_token-у установил время жизни день, а refresh_token-у 3 года.
1 день жизни access_token снижает нагрузку на сервер, если выписывать его каждые 30 минут.
а имея рефреш токен позволяет отозвать сессию если юзер скомпрометирован.
буквально месяц назад звонила знакомая 50 летняя бухгалтер и спрашивала, что значит когда ms office пишет, что скоро кончится 60 дневный trial период. это она новый ноутбук купила.
на iOS всё как часы
как я понял, использует бизнес — апп, а не тот, который юзает пользователь из магазина.
зачем вы ненавидите набор байт?
может новопассит попить?
т.е.?
а почему не купили?
LinkedIn принадлежит Microsoft.
У Microsoft нет датацентров в РФ? Т.е. покупаешь Azure, а потом его заблокируют?
На мой взгляд, это та же cookie с сессией, только сбоку.
Но даёт сложности в виде проверки — если access_token протух, то через refresh получить новый access_token и повторить запрос. Ещё +1 обёртка над сетевыми запросами.
В МП. Native наше всё. Ну, и по большому счету, имхо, нет разницы между native и браузером. Меня «радует» рекомендация PCI DSS для ввода данных банковских карт — давать вводить CC number и CVC2 в МП это не безопасно, а через webview это нормально.
При смене пароля можно отозвать refresh токен. А можно и не отзывать. Ведь возможность работы с функциональностью МП != от значений логина и пароля.
Т.е. все пляски из-за того, чтобы просто не ломать oauth, но при этом нарушаем РЕКОМЕНДАЦИЮ, чтобы refresh давать только server side приложениям.
Задача: юзер вводит логин и пароль, работает в МП. Через месяц юзер снова запускает МП, и продолжает работать.
В связи с тем, что Authz(Authn)(Identity)Server поддерживают только OAuth и OpenID, эту задачу я решил так: access_token-у установил время жизни день, а refresh_token-у 3 года.
1 день жизни access_token снижает нагрузку на сервер, если выписывать его каждые 30 минут.
а имея рефреш токен позволяет отозвать сессию если юзер скомпрометирован.
это как?
буквально месяц назад звонила знакомая 50 летняя бухгалтер и спрашивала, что значит когда ms office пишет, что скоро кончится 60 дневный trial период. это она новый ноутбук купила.
Давид Ян?