Можно ли перенаправить текущий токен доступа или запросить новый токен для прокси - PullRequest
0 голосов
/ 01 января 2019

TL; DR

Мне нужно создать прокси между клиентским приложением и webapi, например,

клиентское приложение <---> прокси <---> webapi (защищено oauth2)

Должен ли прокси-сервер просто перенаправить токен доступа в webapi или запросить новый токен доступа?

Подробно

В настоящее время есть клиентское приложение и веб-интерфейс.Чтобы получить доступ к webapi, клиентскому приложению необходимо предоставить токен доступа.

т.е. client <---> webapi (защищено oauth2)

Все работает, как и ожидалось.

Однако по какой-то причине появилось новое требование - создать прокси-сервер с использованием ядра asp.net между клиентом и webapi.

т.е. клиент <---> прокси <---> webapi

Код прокси выглядит так:

[Route("api/[controller]")]
[ApiController]
public class ProxyController : ControllerBase
{
    [Authorize]
    [HttpGet]
    public async Task<ActionResult<object>> Invoke()
    {
        using (HttpClient client = new HttpClient())
        {
            //GET ACCESS TOKEN FROM CURRENT REQUEST
            var accessToken = await HttpContext.GetTokenAsync("access_token"); ;
            client.SetBearerToken(accessToken);
            var response = await client.GetAsync("https://demo.identityserver.io/api/test");
            if (!response.IsSuccessStatusCode)
            {
                return response.StatusCode;
            }
            else
            {
                var content = await response.Content.ReadAsStringAsync();
                return content;
            }
        }
    }
}

КакВы можете видеть, я просто использую текущий токен доступа, а затем делаю запрос к реальному API.

Ради безопасности, я понятия не имею, нормально ли использовать текущий токен доступа.Должен ли я запросить новый токен доступа для прокси и сделать запрос к настоящему API?

1 Ответ

0 голосов
/ 03 января 2019

Если вы хотите получить ответ из учебника, тогда да, ваш proxy api должен стать и ресурсом API, и клиентом.У него должна быть новая область действия, для которой внешние клиенты должны запрашивать токен доступа, а не ваш фактический API.Затем он должен также использовать поток учетных данных клиента и токен запроса с областью действия вашего фактического API и использовать этот токен при передаче исходного запроса на целевой URL назначения.

Сказав это, я лично имел дело с подобнымситуация и в конечном итоге просто прокси токены, хотя наш оригинальный подход был использовать поток, который я описал ранее.Основная причина изменения мнения заключалась в том, что бизнес-требования развивались, и была необходимость в более детальной клиентской авторизации в реальных API.Мы пытались использовать пользовательские гранты, имитирующие олицетворение внешнего клиента, но в целом иметь дело с кошмаром.

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

...