Mixing
Is it OK to forward the current access token or request new token for Proxy
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?
asp.net-web-api proxy oauth-2.0 openid-connect
asked Jan 1 at 4:41
CharlieCharlie
459213
add a comment |
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?
asp.net-web-api proxy oauth-2.0 openid-connect
asked Jan 1 at 4:41
CharlieCharlie
459213
add a comment |
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?
asp.net-web-api proxy oauth-2.0 openid-connect
asked Jan 1 at 4:41
CharlieCharlie
459213
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?
asp.net-web-api proxy oauth-2.0 openid-connect
asp.net-web-api proxy oauth-2.0 openid-connect
asked Jan 1 at 4:41
CharlieCharlie
459213
asked Jan 1 at 4:41
CharlieCharlie
459213
asked Jan 1 at 4:41
CharlieCharlie
459213
asked Jan 1 at 4:41
CharlieCharlie
459213
asked Jan 1 at 4:41
CharlieCharlie
459213
459213
add a comment |
add a comment |
1 Answer
1
active
oldest
votes
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.
answered Jan 3 at 2:16
Vidmantas BlazeviciusVidmantas Blazevicius
2,098416
add a comment |
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53993051%2fis-it-ok-to-forward-the-current-access-token-or-request-new-token-for-proxy%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
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.
answered Jan 3 at 2:16
Vidmantas BlazeviciusVidmantas Blazevicius
2,098416
add a comment |
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.
answered Jan 3 at 2:16
Vidmantas BlazeviciusVidmantas Blazevicius
2,098416
add a comment |
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.
answered Jan 3 at 2:16
Vidmantas BlazeviciusVidmantas Blazevicius
2,098416
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.
answered Jan 3 at 2:16
Vidmantas BlazeviciusVidmantas Blazevicius
2,098416
answered Jan 3 at 2:16
Vidmantas BlazeviciusVidmantas Blazevicius
2,098416
answered Jan 3 at 2:16
Vidmantas BlazeviciusVidmantas Blazevicius
2,098416
answered Jan 3 at 2:16
Vidmantas BlazeviciusVidmantas Blazevicius
2,098416
2,098416
add a comment |
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53993051%2fis-it-ok-to-forward-the-current-access-token-or-request-new-token-for-proxy%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
