Warm tip: This article is reproduced from serverfault.com, please click

Is it OK to forward the current access token or request new token for Proxy

发布于 2019-01-01 04:41:22

TL;DR

I need to create a Proxy between the client app and the webapi, e.g.

client app <---> proxy <---> webapi (secured by oauth2)

Should the proxy just forward the access token to the webapi, or request a new access token?

Detailed

Currently, there're a client app and a webapi. To access the webapi, the client app needs to proivde the access token.

i.e. client <---> webapi (secured by oauth2)

Everything works as expected.

However, for some reason, there's a new requirement which is to create a proxy server using asp.net core in between the client and the webapi.

i.e. client <---> proxy <---> webapi

The proxy code is just like below:

[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;
            }
        }
    }
}

As you can see, I just use the current access token and then make the request to the real api.

For security's sake, I've no idea is it Ok to make use of the current access token. Should I request a new access token for the proxy and make request to the real api?

Questioner
Charlie
Viewed
0
Vidmantas Blazevicius 2019-01-03 10:16:43

If you want a textbook answer then yes, your proxy api should become both an api resource and a client. It should have a new scope which is what the external clients should be requesting access token for and not your actual api. It should also then use client credentials flow and request token with the scope of your actual api and use that token when proxying the original request to the intended destination url.

Having said that, I’ve personally dealt with similar situation and ended up with just proxying the tokens as well even though our original approach was to use the flow I described earlier. Primary reason for the change of heart was that the business requirements evolved and there was a need for more granular client based authorization in the actual api. We tried to use custom grants simulating impersonation of the external client but it was a nightmare overall to deal with.

Lastly, we did a brief assessment of security risks taking this sort of proxy approach and could not identify anything as we owned both the proxy and the actual api and there were only machine to machine communication flows used. However,I would not be surprised if there are some potential security implications of using such approach.