Как совместно использовать токены JWT в нескольких приложениях (веб / мобильные) при использовании сервера идентификации 3.0 и oAuth 2.0

Question

У нас есть сервер Secure Token, построенный на Identity Server 3.0, который управляет безопасностью нескольких приложений, как одностраничных, так и собственных мобильных приложений.И есть сервер (ы) ресурсов (API RESTful, к которому должны обращаться вышеупомянутые приложения).Мобильное приложение дает обобщенное представление информации о клиенте, где пользователю необходимо перейти к одностраничному приложению, чтобы получить полное представление о клиенте.

В настоящее время мобильное приложение (Cordova) получает сводную информацию о клиенте с сервера ресурсов через клиентское разрешение клиента владельца ресурса и отображает список сведений о клиенте в виде таблицы в приложении Cordova.

Теперь необходимо открыть информацию о клиенте (представление сведений) в одностраничном приложении (AngularJS) без повторного входа пользователя.На данный момент мобильное приложение имеет токен, который может получить доступ к серверу ресурсов (область действия).

Теперь проблема состоит в том, как передать имеющийся у нас токен в одностраничное приложение (AngularJS) без его отправки (токен).) в URL.Не могли бы вы пролить свет на то, как лучше всего справиться со сценарием?

Answer 1

Вам необходимо поведение единого входа (SSO) между двумя приложениями.Но есть проблема с текущим потоком, который вы используете.

Поскольку вы в настоящее время используете Resource Owner Client Credential Grant, вы не используете логин конечного пользователя сервера идентификации.Я полагаю, что вы получаете учетные данные конечного пользователя из мобильного приложения и вызываете конечную точку токена для получения токенов.

С точки зрения OAuth / OpenID Connect, SSO реализован поверх файлов cookie браузера.Как это работает?

1. App A follow a flow that utilize front channel login (ex:-
Authorization code flow with PKCE)
2. End user is present with login page of Identity Server
3. App A completes the flow and obtain tokens
4. App B use a flow utilize front channel login
4. Identity server get login request and see cookies which correlate previously logged in user
5. Because of cookies, log in page is skipped and optionally consent page will be  showed
6. App B completes the flow and obtain tokens

Так работает SSO, и, как вы можете видеть, это требует участия браузера.И я думаю, что это правильный способ решить проблему.

Кроме того, из принципалов OAuth / OpenID Connect клиенту не рекомендуется получать учетные данные конечного пользователя.Ваш клиентский поток в порядке, если приложение имеет привилегию или не может использовать браузер ( source ).