openidconnect.server, сторонние поставщики и перенаправление

В настоящее время я создаю свой сервер openid connect, используя https://github.com/aspnet-contrib/AspNet.Security.OpenIdConnect.Server и идентификацию ядра asp.net в качестве резервного хранилища. Мне известны протоколы, потоки и дыры в безопасности.

Текущая настройка выглядит следующим образом:[server] - сервер авторизации и сервер ресурсов[front-end] - угловое приложение[third-party-provider] - Google[external-app] - второе приложение, которое хочет использовать токен от [server]

Оба [front-end] и [external-app] зарегистрированы как клиенты для [server], Таким образом, им разрешено получать токены. Страница входа построена в [front-end],

Имейте в виду, что страница входа и т. Д. Отображается [front-end] приложение (вместо возврата AuthView из AccountController)

Представьте, что я хочу войти с [external-app] получить личность от [server], Страница входа отображается [front-end], Тогда поток будет следующим:

1. [external-app] -> http://[server]/account/authorize?client_id=[external-    
   app-clientid]&response_type=token&redirect_uri=http://[external-app- 
   redirecturi]
2. [front-end] -> matches route -> show login page
3. [front-end] -> user clicks on login with google
4. [front-end] -> redirect to 'http://[server]/account/authorize/connect?
   provider=Google&redirect_uri=http://[front-
   end]/account/thirdparty/authorized&response_type=code&client_id=[front- 
   end-clientid]
5. [server] -> no identity found, save request in session and let the user 
   login at the [third-party] (using ChallengeResult and also passing in the 
   request id which was stored in session)
6. [third-party-provider] user logs in
7. [front-end] -> http://[front-end]/account/thirdparty/authorized recieved 
   the code
8. [front-end] -> exchange authcode for token with [server] using 
   http://[server]/account/token&grant_type=authorization_code&code=
   [code]&redirect_uri=http://[front-
   end]/account/thirdparty/authorized&client=[front-end-clientid]
9. [server] -> generate claims and return token
10. [front-end] -> token recieved

Вещь, которую я пропускаю (и это может быть недостаток реализации, недостаток мысли или что-то еще), это то, что мне нужно перенаправить обратно к [external-app] с данным токеном. Мне нужно сделать это на [front-end]? Я чувствую себя не в своей тарелке, и я уверен, что неправильно смешиваю / подбираю материал. Может кто-нибудь мне помочь?

Заранее спасибо!

PS да, я знаю, должен быть https. Выше, например, цель;)

1 ответ

Решение

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

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

Подумайте о переработке вашего потока, чтобы ваше интерфейсное приложение перенаправляло ваших пользователей на сервер авторизации, который сам перенаправит их на ваше внешнее приложение.

Другие вопросы по тегам