Что-то я совсем разочаровался и в oauth2, и в OpenID Connect. Долго долго думали и придумали какую-то слаборасширяемую фигню, которая обросла костылями и несовместимостями и протеворечиями стандарту. Из всего этого +- API сохраняют общий смысл flow в тех местах, где это уместно

OAuth2 авторизация через OAuth2 социальных сетей https://medium.com/schors/...13a4dc2c5#.fl7dhovjp

Я правильно понимаю, что у OAuth2 refresh_token это дикий костыль, нашлепнутый вдогонку? Если смотреть RFC, то там есть например ситуация, когда сервер может перевыпустить refresh_token по своему разумению и удалить остальные. Однако, ситуация получается скользкой. Если подразумевается, что одним приложением (client_id) можно пользоваться в нескольких инстансах (с двух телефонов на андроиде - почему нет), то такая ситуация приведет к вдруг внезапной потере refresh_key для одного из приложений. И дальше все выкручиваются как могут. Так?

Я правильно понимаю, что по идеологии OAuth 2, клиент всегда должен получить access_token на сервере авторизации (включая беспарольный), а к сервисам лезть уже с access_token? Например, в API Вконтакте регистрация пользователя сделана вразрез с этим подходом. Так?