Re: [Dev] [APIM 2.0] Revoked access and revoked refresh tokens returning with http response header

We usually recommend to expose token endpoint via API. So we can remove relevant transport headers at gateway. So user will not see them only internal traffic will have those headers. Thanks, sanjeewa. On Mon, Jun 27, 2016 at 11:07 AM, Kavitha Subramaniyam wrote: > Hi Nuwan,

Re: [Dev] [APIM 2.0] Revoked access and revoked refresh tokens returning with http response header

Hi Nuwan, Ok, I understand the situation now and agree with you. Since we don't have any solution at the moment, you can make as an improvement for future reference if need.. Thanks, Kavitha On Mon, Jun 27, 2016 at 9:42 AM, Nuwan Dias wrote: > Yes, this is not part of the

Re: [Dev] [APIM 2.0] Revoked access and revoked refresh tokens returning with http response header

Yes, this is not part of the spec. Its implemented as such because this is a problem which is unique to us and its a result of the product's architecture. And there is no known generic solution yet on how to handle it when using third party key managers. But that shouldn't mean we should at least

Re: [Dev] [APIM 2.0] Revoked access and revoked refresh tokens returning with http response header

Hi Nuwan, Thank you for the response.. I have been understood the behavior and there is no security risk when revoked token values returning to the response endpoint. But as per my understanding, when we use third party key manger that will not let to know the gateway to do cache clear like in

Re: [Dev] [APIM 2.0] Revoked access and revoked refresh tokens returning with http response header

Any idea why its bad? That jira doesn't clearly say why. It won't return anything in those headers if someone sends invalid values. So I'm wondering how it can be bad. The reason we use these return values is to clear the gateway cache. When the key manager refreshes a token, the Gateway doesn't

Re: [Dev] [APIM 2.0] Revoked access and revoked refresh tokens returning with http response header

Hi Nuwan, Kavitha was asking, RevokedAccessToken & RevokedRefreshToken are getting in the header because it was requested requirement by APIM team [1] ? Jira [1] says it's a bad implementation. So are we going to fix[2] ? [1] https://wso2.org/jira/browse/IDENTITY-4112 [2]

Re: [Dev] [APIM 2.0] Revoked access and revoked refresh tokens returning with http response header

Can you explain what the issue here is? You have raised the ticket as a bug but you've forgotten to describe what the bug actually is? On Fri, Jun 24, 2016 at 5:39 PM, Kavitha Subramaniyam wrote: > Hi apim team, > A jira has been raised to track this issue in [1] > > [1]

Re: [Dev] [APIM 2.0] Revoked access and revoked refresh tokens returning with http response header

Hi apim team, A jira has been raised to track this issue in [1] [1] https://wso2.org/jira/browse/APIMANAGER-5098 Thanks, On Thu, Jun 23, 2016 at 6:31 PM, Kavitha Subramaniyam wrote: > Hi team, > Highly appreciate your update on this. > > Thanks, > > On Wed, Jun 22, 2016 at

Re: [Dev] [APIM 2.0] Revoked access and revoked refresh tokens returning with http response header

Hi team, Highly appreciate your update on this. Thanks, On Wed, Jun 22, 2016 at 2:28 PM, Kavitha Subramaniyam wrote: > Hi team, > > I observed that both revoked access and revoked refresh tokens were > returning in http response header [3]. > setup : IS as KM > - apim 2.0.0

[Dev] [APIM 2.0] Revoked access and revoked refresh tokens returning with http response header

Hi team, I observed that both revoked access and revoked refresh tokens were returning in http response header [3]. setup : IS as KM - apim 2.0.0 17th nightly build - IS 5.2.0 19th build - Token encryption enabled Could you please confirm that this behavior is not resolved purposely in apim