Допустим, существует протокол, подобный OAuth (назовем его MyAuth), но используемый для аутентификации внешнего интерфейса вашего приложения с помощью внутреннего интерфейса вашего приложения.
Чтобы понять, почему OAuth и MyAuth различаются, сначала знайте, что у них обоих есть токены обновления, которые являются долгоживущими, и токены доступа, которые являются недолговечными. Кроме того, если party1 необходим доступ к party2, party2 должен будет сгенерировать эти токены, а party1 должен каким-то образом хранить оба этих токена для поддержания доступа.
Об OAuth:
У нас есть три стороны (есть и другие типы): бэкэнд App1, веб-интерфейс App1 и бэкэнд App2.
Здесь цель состоит в том, чтобы предоставить доступ к бэкенду и веб-интерфейсу App1, доступ к бэкенду App2 от имени пользователя.
Только здесь бэкэнду App1 и бэкенду App2 можно доверять как защищенным сторонам.
О MyAuth:
У нас есть две стороны: бэкэнд App1, фронтенд App1.
Здесь цель состоит в том, чтобы предоставить веб-интерфейсу App1 доступ к бэкенду App1 от имени пользователя (это относится ко всем приложениям после входа пользователя в приложение).
Здесь только бэкэнд App1 является доверенной стороной.
Поскольку токены обновления являются долгоживущими, получение несанкционированного доступа к ним может быть серьезной проблемой. Таким образом, в потоке OAuth он спроектирован таким образом, что токены обновления бэкэнда App2 хранятся только на бэкэнде App1 (который является доверенной стороной). И только маркер доступа бэкэнда App2 (который недолговечен) отправляется на веб-интерфейс App1. В MyAuth у нас нет доверенной стороны для хранения токена обновления бэкэнда App1. Это означает, что вы храните токен обновления в месте, где его можно относительно легко украсть, что является проблемой безопасности. Таким образом, хотя OAuth не должен решать эту проблему как таковой, MyAuth делает.
Чтобы узнать больше о безопасности сеанса и различных типах потоков, см. https://hackernoon.com/all-you-need-to-know-about-user-session-security-ee5245e6bdad