Мы пытаемся интегрироваться с внешним сторонним REST-API, защищенным с помощью oAuth2, но сервис на самом деле не является поставщиком удостоверений, поэтому я не уверен, какую терминологию я ищу. Очевидно, что когда дело доходит до «asp. net core» и «oauth», возникают миллионы обращений, связанных с добавлением его в качестве провайдера идентификации, но я не думаю, что это то, что мы хотим.
Вот как я ожидаю, что это сработает, основываясь на том, что я видел в других приложениях saas:
- Пользователь заходит на сайт
- Пользователь смотрит на какую-то «третью» -party Integration "и щелкает, чтобы добавить этот
- Браузер пользователя направляется на другой сервис для входа в систему
- При успешном входе пользователь перенаправляется назад, и у нас есть доступ к предъявителю + refre sh токен, который мы храним (?) И используем.
Некоторое использование этого API происходит в ответ на действия пользователя (для получения результатов используйте refre sh), но некоторые также являются просто фоновой работой поэтому я предполагаю, что мы храним эту информацию и используем неявный поток для повторного обновления sh токена до тех пор, пока мы не отменим его.
Что asp. net терминология ядра, которую я ищу как бы кто-то правильно описал этот поток в oAuth условия? Мы запутываемся между авторизацией, аутентификацией, провайдерами, обработчиками, промежуточным программным обеспечением и т. Д. c.
С точки зрения этого потока сторонних API, если люди хотят знать, вот что требуется:
- Мы вызываем указанную конечную точку c, которая сообщает нам правильные конечные точки авторизации и токена
- Затем мы перенаправляем на конечную точку авторизации, которая предоставляет пользователю страницу входа удаленной службы.
- Пользователь входит в другой сервис и перенаправляется обратно, а код и grant_type = authorization_code предоставляются через URL
- Мы вызываем конечную точку токена с этой информацией, чтобы получить окончательный носитель + refre sh токен