Я просматривал документацию Doorkeeper и заглянул в исходный код.Однако мне еще предстоит понять, как Doorkeeper генерирует свои токены.Документация сфокусирована на том, как использовать Doorkeeper, но они не объясняют, как они генерируют токены, и не объясняют, почему они используют безопасную стратегию генерации, проверки и отзыва токенов.Oauth2 - это протокол, который ничего не говорит о том, как генерировать защищенные токены обновления и токен доступа, сам по себе совместимость с Oauth2 ничего не говорит о технологии, используемой для обработки генерации и проверки токенов.
Может кто-нибудь объяснит, как привратник генерирует свой доступтокен и обновить токен, и почему это безопасно.Как Doorkeeper обрабатывает отзыв токенов?
По сравнению с системой токенов по умолчанию для владельцев дверей, если все, что мне нужно, это обрабатывать токены обновления и доступа для собственного мобильного приложения, и мне не нужны остальные функции Oauth2, будет ли этобезопаснее свернуть мою собственную стратегию «обновить токен», используя, например, RSA с 1 закрытым ключом на пользователя, идентифицированного извне с помощью uuid, и сохраняя открытый ключ на сервере и используя вызов шифрования в стиле ssh через API, или используйте JWT с RS512 ииспользуйте открытый ключ для проверки подписи токена для аутентификации пользователя.Отмена в обоих случаях будет осуществляться путем внесения в белый список открытых ключей.
Мой вопрос не о протоколе OAuth2, который я понимаю, или о безопасности привратника, а о моем незнании того, как привратник обращается со своими токенами,Я знаю, что изобретать велосипед не очень хорошая идея, и в то же время я не хочу использовать то, чего не понимаю, и не понимаю, как привратник обращается с жетонами.