Контекст
Я разрабатываю решение с
- Два клиента, мобильный и SPA.
- Сервер авторизации под моим контролем.
- Сервер ресурсов / поставщик удостоверений, который предоставляет пользовательские данные и функции через API.
Я использую OAuth2. 0, поскольку он может предоставить преимущества , такие как возможность сторонних приложений легко интегрироваться с моим сервером аутентификации / IdP, будь то доступ к пользовательским данным или функции API. Это также позволило бы клиентам интегрироваться с другими IdP и, в конечном итоге, перенести свои данные в мою.
Поток OAuth
Аутентификация
Во время потока OAuth существует перенаправление для аутентификации пользователя на сервере авторизации. В этот момент пользователь вводит учетные данные и соглашается с областями / утверждениями, к которым клиенты хотят получить доступ. В случае сторонних клиентских приложений я понимаю, что:
- Мобильный: последние RFC рекомендуют настраиваемые вкладки браузера для мобильных приложений.
- SPA: Быть на основе браузера, здесь простое перенаправление.
Но это тот случай использования, когда это стороннее клиентское приложение, делегирующее аутентификацию и управление учетными записями моей системе IdP. Это гарантирует, что мобильное приложение не сможет sn oop на учетные данные пользователя (и в конечном итоге использовать решение IdP, поэтому нет необходимости вводить учетные данные).
В моем случае я владею как клиентом, так и остальными .
Мой первый вопрос: Поскольку я являюсь владельцем приложения, будь то мобильное или веб-приложение, нужно ли мне обязательно осуществлять перенаправление на пользовательский интерфейс, размещенный на моем IdP? Или я могу иметь форму непосредственно как часть мобильного / веб-приложения и аутентифицировать пользователя через REST (и затем следовать остальной части потока OAuth, чтобы доставить AccessToken + IdToken для OID C)?
Scopes
Когда это сторонние клиентские приложения, я понимаю, что мы должны отобразить конечному пользователю данные (области / утверждения), к которым клиент хочет получить доступ. Пользователь должен дать явное согласие и знать, какие данные будут использоваться приложением.
Но в моем случае, поскольку я являюсь владельцем приложения, могу ли я просто иметь страницу «Условия и положения», которую пользователь разрешает использовать в приложении, и пропустить утверждение областей / утверждений в потоке OAuth?
Короче говоря, что является лучшей практикой и почему, когда не участвует третья сторона?