#api #oauth #oauth-provider #access-token
#API #oauth #oauth-провайдер #токен доступа
Вопрос:
В разрабатываемом нами API токены доступа уникальны. При этом я имею в виду, что для каждого приложения и пользователя может быть только один токен доступа.
Следствием этого является то, что если пользователь аутентифицирует одно и то же стороннее настольное приложение на двух компьютерах, только у второго будет действительный токен доступа, а первому придется снова пройти процесс аутентификации (первый токен доступа будет признан недействительным).
С точки зрения пользовательского интерфейса это неоптимально. С точки зрения безопасности это дает незначительное преимущество.
Любопытно узнать, как другие внедрили токены доступа в свои API. По одному на пользователя и приложение или несколько?
Ответ №1:
Токены доступа должны быть уникальными, но отношение между [пользователь, приложение] и [токен] должно быть один ко многим. Тогда как в вашем случае это один к одному. Это не имеет ничего общего с OAuth как протоколом, а скорее с деталями вашей реализации.
Комментарии:
1. Да — это связано с нашей реализацией. Видите ли вы какие-либо недостатки в реализации «один ко многим»? В противном случае я не совсем понимаю, почему мы выбрали бы один к одному из-за незначительных сбоев в системе безопасности.
2. Я думаю, что большинство реализаций используют отношение «один ко многим» именно по указанным вами причинам. Возможно, вы захотите выбрать один к одному, чтобы ограничить количество входов пользователя в систему одним, но это звучит как функциональность приложения и отсутствие oauth.
3. Чтобы разъяснить эту проблему. Не было бы нормально использовать уже действительный токен доступа, если он есть? Это значительно упростило бы дело.
4. Ну, это все равно, что использовать один и тот же пароль на разных веб-сайтах. Вероятно, это нормально, но может быть проблемой безопасности.
5. Хм, я не уверен, что согласен с тем, что это одно и то же. Вам все равно придется пройти полный «танец» OAuth, чтобы получить уже действительный токен доступа, поэтому, если клиент не был скомпрометирован и не потерял свой потребительский ключ и секрет, это не должно быть проблемой. Но я, наверное, слишком теоретизирую 🙂