error "ParseIDToken: missing or invalid id_token in token response" while POSTing to refresh access token

[r-kotagudem]

HI @cfryanr Followed exactly same steps at bookinfo example. all oidc configuration is done as explained. We are receiving below error at the step as follows

The Authservice exchanged the authorization code for tokens by making a call from the Authservice directly to the OIDC provider (as a "backend-to-backend request", rather than another browser redirect)

suspecting DecodeQueryData is returning null causing the issue. Here's the code and state query parameters return by oauth server https://hostname/productpage/oauth/callback?code=ZGdFVG94TmVpOFhtbnhkZ01Ma09tZz09fnloMzFMcmg4K0I1c2lmQWJnT0todDBrdTh3ZDNjcTh5cCtXVm9yUXpoMEI0TGlocUtqYTZCQjk2VVk1bGpyZUpwREpYS1l1RHRoSmVzcFVKY3pvaUpuWEZRNzBaWFovWFFodThoUkJlNVcwb2lZOHRHTnk0dlZDeDl4VTNhMEtlV2tCa2wwZzFDTndQZ3N3ZC9HTnl5SXAxMHV5eUd0RGlaeWx0blpGVHdLeDJUWDUxUC9UUGpNa0tjMmJVV0ZnNTZNaHZhWEdYK0FhSWFGQ0tVeWw0c2NnNmNZL0FKTlhBaDhzTDdjVy9wSTF0WGRwRFo1a0Qwc3hOck1sdVlNeWlaSXBQaVF0dHdsVnBjUkNSbHRTLy81eGV3Ukh6VW44V24vbVg3OThoYlRGN2ZJYVdNK0JxUGFTc3NRYTIzK3JrcE9kMVpvYitjdWFQQWpXeEw5eDJCYWt2RmlpUTZlanNMN2U2WXQ4NkdYRVNGTmJmcTRoQjJQcFUrTmF5dmEyL3VpRmdKeGdkRUJWS2s5Ym9XQ1FZeEd5V2daM2plVmhPaGplMUFjYUlIdWQ4ZW5FSkRGWGtNeWRiVkFJajVrRlNwS0owMkRGM2VySzdnU2lsK3J4bFBCRjdDU1JmQW5WQk13TWh5Rk5uU2sxVmtxSWRIeTAyZllXcklOSktrTyt4Vmw4V0ViMzBWN2EyQlkzUVNGSE9VSWFiUHBUWmhMMWEySDNtN3ZoYU1rS1hudlJwYVd3ZDZQOXZzckdjOCtST3MrUVJtaEt4TGw4TUpxblE2TExETXc9PQ==&state=kWGQuZHwzvV615YJQEYzv1LIvqQYSV6QfLcIO8kajB8

curl with post to token endpoint , can get the access/idtoken with this auth code though.

using OAM12c-Oauth2 as authorization server Please help fix this issue.

[cfryanr]

Hi @r-kotagudem,

Your OIDC Provider is redirecting back to the authservice with a code that includes reserved = characters without URI encoding the = characters, which is confusing the Authservice's URI parser.

[r-kotagudem]

Hi @r-kotagudem,

Your OIDC Provider is redirecting back to the authservice with a code that includes reserved = characters without URI encoding the = characters, which is confusing the Authservice's URI parser.

Thanks for reply. When we try build Authorization URL manually and access It in browser, after login it gives code without ==

[cfryanr]

Can you tell what's different between the authorization URL that you manually construct versus the authorization URL that the Authservice constructs for you? You should be able to see the exact authorization URL that was constructed by the Authservice in your browser's network debug window, since the Authservice returns that redirect to your browser.

[r-kotagudem]

Can you tell what's different between the authorization URL that you manually construct versus the authorization URL that the Authservice constructs for you? You should be able to see the exact authorization URL that was constructed by the Authservice in your browser's network debug window, since the Authservice returns that redirect to your browser.

I agree, we are implementing lua filter to url encode the authcode so address this.

We are facing below issue now,

Could you please help find the cause of the issue? Below are the error in authservice logs and requests in browser

Request URL: https://service hostname/productpage

https://authserverhostname/oauth2/rest/authorize?client_id=TestClient&nonce=OG7ARhksty-kk8sAfBv48w9tcm29J25k_baqDlp2OAk&redirect_uri=https%3A%2F%2Fservicehostname%2Fproductpage%2Foauth%2Fcallback&response_type=code&scope=ResServer1.email%20ResServer1.profile%20ResServer1.scope1%20openid&state=NLVJdna5r79h_pC3FT_md1xGTa08vrYKTJ40WHQmozc

http://authserverhostname/oam/pages/consent.jsp?state=MUFoakMrQ3VIQjd0QlhsVWNQaHM3Zz09fkdDbHNhK1kyaTFjL3pQYlprRjZIVnJVeHZzLzlKQU52RXhEeEtSZXQ4bmZjWkZuRE5OQkw4cGVtVDgwNDFNb2ZKQTNPQTV1WW1nWU5mNUhKN1NDbUkrZ25NcGlPdHRzU0hYQzgxVjEyRjB0aFU5TGtkeXUwRUR5SEpSOVpXcmJBdzI1ODVhbDFaV2QraDh4M0VlSVMvT0VzNVVUVUlyeWVRa1ViWWJ6cXM2SnI1R0VaczdjMUlzNTlQR0pJTmJsVWs5SC9BWG1RMlZQN3FYN29XTjRDRmVIOWVFMlgvNzhDSmhFRFpiSjlVSFc2WE43djVCbkpXemhIcjJ3VC94YmVwWG5sU3Fmd3pkRzU4ZjZTOUcxNUlVY2NNY1hXeWw3MWFFZDVscWdaQ0JQRlkrM1JiNk1CbXQ2RHRLMXNvQ25TclRFUUpjYmdHcm5jaEVTN0NKY1E5MVIrREtBbm8yZXJsRmRKYVR4UkhGUT0=&scopes=ResServer1.email+ResServer1.profile+ResServer1.scope1+openid&client_id=TestClient

Request URL: http://authserverhostname/oauth2/rest/approval Request Method: POST

Request URL: https://service hostname/productpage/oauth/callback?code=dm1ZdUVIVDhXM0tEV203TmIwQVh6QT09fi9VQlNKTUcwSHFKNWw4NTNnWUQxWGxYckhkWDh0SnY5N0dtZXZPeU5abUJ3RmtKZ2pNLzJrcmU2NzNzMktPZHFxdU9YL1k5VE85c1pUS1NTeVhuN1htQS9LRWZwdnRGRXJwZm5BZ0x4NmwyZWJadmJUQ3dXV0YrYmVBOWtadytodzhYSERPeUtjWHJZZHg1REZyVE1vZ2l5QkRQWGFoa0pKWnB1aVZhaXI5UHhLQStCMTIzQjlGRUdBamF6NVJxb0c4ZHVIdllvLytxV0VqK21oUFdjaFc2YUxBTzVyQ25jWU1nblRjeS9RMUsyYjA4ZGlHZUhSWmlKSFpvMkV5UUluQ2JwRWdyT1o2Z0Jub3NMc1NTdTJ3b2RFdGxvNS9zaHY4UHZWeXAwNUpkZVhDUzRsdlhaMlloWDU2dERmMGZWUm1iRytSU3dUTFNiVkU4WFlQZGN4bWxEbGgwNGRtTHFCSm5tZm54NFJrQ2x1Wmdua3lEVWVjMDhhdm1rU2RCVDZLdWhuTzZwcHRNTnU2aU8xcVg1aXVNbENoWG5LL05BS2NVRnFIZ0MrekRBeVl6bVZjTEtVYzdWTUhXaUppTVhUVmZJTFVWYk4wakl0NVZFdG51S2tGVkNpODlXZDNEd3E2VURQV0wzUUoyZGczclY4bm1zVFJsOEFkWXVmNlh2NVF4RUtySnpFNlNINHYzNXdqZmQ0SzZ4S0NOTHlYaGxSWFpQVEZiZUNKV0dkZE9VanlBWUs4Z0Z2Rk1IN2Z1WVVTdU8rRzZ3WUF1VzdUSlc1dlZMNS9pNHVQRXNwSy9PamN3a2tuWllxSWpRdVFXM1diTkVVMzhKSGI3RDdmOVM0M2d1ejhFMnM5elhxUzdjSHhLM09VRXNFRDZROU1WNWVzVjJIbGZOMFlXMFZ0aXZkbHdKWkh2Q3k3RElpSXpO&state=NLVJdna5r79h_pC3FT_md1xGTa08vrYKTJ40WHQmozc

[cfryanr]

It looks like the Authservice is complaining that your OIDC Provider did not put a nonce claim in the returned ID Token. That is illegal according to the OIDC Spec: https://openid.net/specs/openid-connect-core-1_0.html#IDToken

[r-kotagudem]

Hi @cfryanr

thank you for continued support on this.

We are able to complete oidc flow and login to app succesfully

however, when the token expires. it sends post to get refresh token. However authservice complains invalid id_token in token response.

We are receiving only accesstoken in the resfresh repsonse, not an id token. could you please help on this? thanks again

[2020-07-03 05:36:09.918] [console] [debug] Call from @10.162.43.43 to @10.162.41.173 [2020-07-03 05:36:09.918] [console] [trace] MatchesCallbackRequest: checking handler for ://apphostname/productpage [2020-07-03 05:36:09.919] [console] [info] RefreshToken: POSTing to refresh access token [2020-07-03 05:36:09.919] [console] [trace] Post [2020-07-03 05:36:09.919] [console] [info] Post: opening connection to oamserverhost:443 [2020-07-03 05:36:10.009] [console] [info] ParseIDToken: missing or invalid id_token in token response [2020-07-03 05:36:10.010] [console] [info] ParseRefreshTokenResponse: Updating access token. [2020-07-03 05:36:10.010] [console] [info] ParseRefreshTokenResponse: Updating access token expiration. [2020-07-03 05:36:10.010] [console] [info] Process: Updated session store with newly refreshed access token. Allowing request to proceed. [2020-07-03 05:36:10.010] [console] [trace] Request processing complete [2020-07-03 05:36:10.010] [console] [trace] Processing completion and deleting state [2020-07-03 05:36:19.529] [console] [info] operator(): Starting periodic cleanup (period of 60 seconds) [2020-07-03 05:36:19.529] [console] [info] DoPeriodicCleanup: removing expired sessions from chain idp_filter_chain [2020-07-03 05:36:28.915] [console] [trace] Creating processor state [2020-07-03 05:36:28.915] [console] [trace] Launching request processor worker [2020-07-03 05:36:28.915] [console] [trace] Processing request [2020-07-03 05:36:28.915] [console] [trace] Check [2020-07-03 05:36:28.915] [console] [trace] Matches [2020-07-03 05:36:28.915] [console] [debug] Check: processing request ://apphostname/productpage with filter chain idp_filter_chain [2020-07-03 05:36:28.915] [console] [trace] New [2020-07-03 05:36:28.916] [console] [trace] OidcFilter [2020-07-03 05:36:28.916] [console] [trace] Process [2020-07-03 05:36:28.916] [console] [debug] Call from @10.162.43.43 to @10.162.41.173 [2020-07-03 05:36:28.916] [console] [trace] MatchesCallbackRequest: checking handler for ://apphostname/productpage [2020-07-03 05:36:28.916] [console] [info] RefreshToken: POSTing to refresh access token [2020-07-03 05:36:28.916] [console] [trace] Post [2020-07-03 05:36:28.917] [console] [info] Post: opening connection to oamserverhost:443 [2020-07-03 05:36:29.022] [console] [info] ParseIDToken: missing or invalid id_token in token response [2020-07-03 05:36:29.022] [console] [info] ParseRefreshTokenResponse: Updating access token. [2020-07-03 05:36:29.022] [console] [info] ParseRefreshTokenResponse: Updating access token expiration. [2020-07-03 05:36:29.022] [console] [info] Process: Updated session store with newly refreshed access token. Allowing request to proceed. [2020-07-03 05:36:29.023] [console] [trace] Request processing complete [2020-07-03 05:36:29.023] [console] [trace] Processing completion and deleting state

[cfryanr]

There are two expiration times involved in refresh. One for the ID token and one for the access token.

When the authservice first exchanges the authcode for tokens, does the returned ID token have any claims related to expiration time? It’s supposed to have an exp claim. See https://openid.net/specs/openid-connect-core-1_0.html#IDToken

The access token’s expiration time does not live inside the token itself. Instead it is a field called expires_in in the Json response of the request made when the authservice exchanges the authcode for tokens. Can you see if that is included in the response? See https://openid.net/specs/openid-connect-core-1_0.html#TokenResponse

Refresh endpoints are not required to return ID tokens, but the hope is that if the ID token expired then maybe the refresh endpoint will return a new one. See https://openid.net/specs/openid-connect-core-1_0.html#RefreshTokenResponse

If you look at the original token response, can you tell if it was the ID token or the access token that expired and caused the authservice to attempt a refresh?

[r-kotagudem]

There are two expiration times involved in refresh. One for the ID token and one for the access token.

When the authservice first exchanges the authcode for tokens, does the returned ID token have any claims related to expiration time? It’s supposed to have an exp claim. See https://openid.net/specs/openid-connect-core-1_0.html#IDToken

The access token’s expiration time does not live inside the token itself. Instead it is a field called expires_in in the Json response of the request made when the authservice exchanges the authcode for tokens. Can you see if that is included in the response? See https://openid.net/specs/openid-connect-core-1_0.html#TokenResponse

Refresh endpoints are not required to return ID tokens, but the hope is that if the ID token expired then maybe the refresh endpoint will return a new one. See https://openid.net/specs/openid-connect-core-1_0.html#RefreshTokenResponse

If you look at the original token response, can you tell if it was the ID token or the access token that expired and caused the authservice to attempt a refresh?

hi @cfryanr Both are expiring in one hour. PFB response when authservice first exchanges the authcode for tokens

[cfryanr]

Ok, I see. The log message missing or invalid id_token in token response is just a warning in this case. You can see in the authservice log that you posted above that the same request successfully updates the access token.

However, it seems like your log also shows that an almost immediate subsequent request causes the refresh to trigger again. This is probably because your ID token is still expired but your server refused to refresh it in the previous refresh attempt. This seems undesirable because now every subsequent request will cause a refresh (until the server refuses to refresh the access token). The only other reasonable behavior that comes to mind would be for the authservice to detect that your ID token is still expired even after the refresh attempt and to end your session, causing you to have to log in again with your OIDC Provider (start a new authcode flow). If your browser still has a session cookie with the OIDC Provider, then the flow might complete with you ever actually seeing a login page. What do you think @tylerschultz ?

@r-kotagudem Do you know why both tokens are expiring in one hour? Is your intention that a user should need to log in again every hour?

[r-kotagudem]

Ok, I see. The log message missing or invalid id_token in token response is just a warning in this case. You can see in the authservice log that you posted above that the same request successfully updates the access token.

However, it seems like your log also shows that an almost immediate subsequent request causes the refresh to trigger again. This is probably because your ID token is still expired but your server refused to refresh it in the previous refresh attempt. This seems undesirable because now every subsequent request will cause a refresh (until the server refuses to refresh the access token). The only other reasonable behavior that comes to mind would be for the authservice to detect that your ID token is still expired even after the refresh attempt and to end your session, causing you to have to log in again with your OIDC Provider (start a new authcode flow). If your browser still has a session cookie with the OIDC Provider, then the flow might complete with you ever actually seeing a login page. What do you think @tylerschultz ?

@r-kotagudem Do you know why both tokens are expiring in one hour? Is your intention that a user should need to log in again every hour?

It is not intentional that user has to log in again every hour, but the response gives id token and access token with expiry time mentioned above. "exp:1594027110" in id_token payload and "expires_in: 3600" field in response denotes 1 hr from the time initial token response was received.

@cfryanr Also, we noticed when id_token and access_token are configured in configmap. the Authorization header(access_token) is not received at backend service(we are printing headers in the backend service)

            "id_token": {
              "preamble": "Bearer",
              "header": "x-id-token"
            },
            "access_token": {
              "preamble": "Bearer",
              "header": "Authorization"
            },

Backend response printing headers on page as json:

{ "x-envoy-internal": "true", "x-request-id": "22285463-88b2-9c23-96ee-54d270d15bd6", "referer": "http://hostname?state=V2Q2R1BZOTF2Uk5TMUZuUkRlNmVCUT09fjJ6R3h3RVRDdmlPeWpneFNJMk5SQzJmalY1RXNIRlkrZTF1aEVmTXNNN3BnR09iSysvV3pHME01dS9HVTZRTzlDVXBISVZ2NVZJRHRBSmdzSVNxc3oxQk81MWdneW0vSnVJNnU0cGJ6c1BEaktzTU1ya3NPdGwyM2JnS2FRMkk1dHN3eGlFN0hqUjA3ZWJ1RlB5UFVqRGg1cGVscWlaNnZQb1dVY1h5c3E2MWY1b1ZKbENFZzEzRzRvLzJsNFNNOXF1eTV3MFhLV1ZLS1hqY0hKa05KeE1NUzVwWUtQTUcyellVWDRTQnF3VDBzWkdCRC9zZEpmMzA0M2h3ci93OE5qalRkSTBhWUo4RnRabFk4ZUFZRzY4Y3NKUW1ERXFtQkEwaXlJZWwvbWoxZGpHeWw5czB5b3QrcWVyU0pSVXhIaFg1NDFjcjhoN0FiUVQyMUQ4KzhrWThmMHlDWG9qUFczTnZJTUdud0FkYz0=&scopes=ResServer1.email+ResServer1.profile+ResServer1.scope1+openid&client_id=TestClient", "content-length": "0", "sec-fetch-site": "cross-site", "x-id-token": "Bearer eyJraWQiOiJUZXN0RG9tYWluIiwieDV0IjoibWltaU9DVTlIVGlTNWl0MFlzZVhVQjdWNVNJIiwiYWxnIjoiUlMyNTYifQ.eyJpc3MiOiJodHRwczovL29hbWRldi5kZXYuc3ByYXRpbmdzdnBjLmNvbTo0NDMvb2F1dGgyIiwic3ViIjoicl9rb3RhZ3VkZW0iLCJhdWQiOlsiVGVzdENsaWVudCIsImh0dHBzOi8vb2FtZGV2LmRldi5zcHJhdGluZ3N2cGMuY29tOjQ0My9vYXV0aDIiXSwiZXhwIjoxNTk0MDg5NzQwLCJpYXQiOjE1OTQwODYxNDAsImp0aSI6Im5HeC0wcXdlcWpzemIzcXhZVDY4RWciLCJhdF9oYXvw8K2XumGYSfs0zeOTEmmhpkOK3hjGECq5R_p4i9Tq6f8dGZcfAXgeiRIBn8iUv_QF8hvN4LKsNZNIw0xTRcu8qvF2McMgtCzL8-efMmgFnJrK8GFTA5Y48WcNdbulg1fKu7ymN0F3IxOI_dERRyQDx3BkVdfUpY4h8qLwOYWoSCf_XD7kx0LLPJvFs-14nRjGxPO6LIK29un4qRefcbcf4EBepH3dTMePwMTCaEVjIT_iK4vk1hA9fXLw5K1Qp45S0OTE7-WEOA0EQ7Nj1x39j_gxMzCYDrsvIfBiLg", "accept-language": "en-US,en;q=0.9", "cookie": "__Host-productpage-authservice-session-id-cookie=31cHZeumzFOZ-1bHgay8lixKuA7jReg9nWkvQBTdqtXe9KTt77NTqzzR96SvLjtqYKp-3gUrTfNTagI5IiO3xw; OAMAuthnHintCookie=1", "x-forwarded-proto": "http", "x-b3-sampled": "1", "x-forwarded-for": "10.162.41.248", "accept": "text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,/;q=0.8,application/signed-exchange;v=b3", "x-b3-traceid": "0b212c88a89aa7edbf492cb254cdb87e", "x-b3-spanid": "bf492cb254cdb87e", "host": "caasidm.msbx.spratingsvpc.com", "upgrade-insecure-requests": "1", "x-envoy-peer-metadata": "ChoKCkNMVVNURVJfSUQSDBoKS3ViZXJuZXRlcwoeCgxJTlNUQU5DRV9JUFMSDhoMMTAuMTYyLjQ0LjM2CpYCCgZMQUJFTFMSiwIqiAIKHQoDYXBwEhYaFGlzdGlvLWluZ3Jlc3NnYXRld2F5ChMKBWNoYXJ0EgoaCGdhdGV3YXlzChQKCGhlcml0YWdlEgDhoMaXN0aW8tc3lzdGVtCl0KBU9XTkVSElQaUmt1YmVybmV0ZXM6Ly9hcGlzL2FwcHMvdjEvbmFtZXNwYWNlcy9pc3Rpby1zeXN0ZW0vZGVwbG95bWVudHMvaXN0aW8taW5ncmVzc2dhdGV3YXkKpwEKEVBMQVRGT1JNX01FVEFEQVRBEpEBKo4BCiAKDmF3c19hY2NvdW50X2lkEg4aDDAzMTc5MTU3NTAyOAolChVhd3NfYXZhaWxhYmlsaXR5X3pvbmUSDBoKdXMtZWFzdC0xZAooCg9hd3NfaW5zdGFuY2VfaWQSFRoTaS0wNmI4OGMyNWFhOWIxMzQ4NgoZCgphd3NfcmVnaW9uEgsaCXVzLWVhc3QtMQo5Cg9TRVJWSUNFX0FDQ09VTlQSJhokaXN0aW8taW5ncmVzc2dhdGV3YXktc2VydmljZS1hY2NvdW50CicKDVdPUktMT0FEX05BTUUSFhoUaXN0aW8taW5ncmVzc2dhdGV3YXk=", "x-envoy-peer-metadata-id": "router~10.162.44.36~istio-ingressgateway-85f45cfddc-hjxtf.istio-system~istio-system.svc.cluster.local", "x-envoy-decorator-operation": "productpage.default.svc.cluster.local:8080/productpage", "cache-control": "max-age=0", "accept-encoding": "gzip, deflate, br", "user-agent": "Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/77.0.3865.120 Safari/537.36" }

[r-kotagudem]

Ok, I see. The log message missing or invalid id_token in token response is just a warning in this case. You can see in the authservice log that you posted above that the same request successfully updates the access token.

However, it seems like your log also shows that an almost immediate subsequent request causes the refresh to trigger again. This is probably because your ID token is still expired but your server refused to refresh it in the previous refresh attempt. This seems undesirable because now every subsequent request will cause a refresh (until the server refuses to refresh the access token). The only other reasonable behavior that comes to mind would be for the authservice to detect that your ID token is still expired even after the refresh attempt and to end your session, causing you to have to log in again with your OIDC Provider (start a new authcode flow). If your browser still has a session cookie with the OIDC Provider, then the flow might complete with you ever actually seeing a login page. What do you think @tylerschultz ?

@r-kotagudem Do you know why both tokens are expiring in one hour? Is your intention that a user should need to log in again every hour?

@cfryanr Is it valid to only consider access token expiry for maintaining the user session. since id_token is not being returned in refresh response? or redirectIdp is best if there is no id_token in refresh response?

[cfryanr]

If the ID token had not yet expired, and only the access token had expired, then I think it would make sense to refresh only the access token and be okay with not getting back a refreshed ID token. In that case the authservice would allow the request to proceed to the app with the old (still unexpired) ID token and the new access token.

On the other hand, if the ID token is expired and the OIDC Provider does not want to refresh it, then one way to interpret that is that we are now outside the window of time during which the OIDC Provider has certified the user's identity. Therefore, we're not sure who this user is anymore. It seems like the safest thing to do would be to start a new authorization flow with the Provider. If the user has a session cookie with the provider, then might not even be prompted with a login page, so it would not be too disruptive.

As an aside, if your OIDC Provider doesn't refresh the ID token, then you might want to consider configuring it to give the ID token a lifetime which is longer than the access token. That way, the access token can be refreshed multiple times during the lifetime of a single ID token.

That's strange that you're not seeing the Authorization header in your app. You should. Is there something else after the authservice stripping it off? Like another Envoy filter?

[r-kotagudem]

@cfryanr

That makes sense, it is better to restart a new authorization flow which is invisible to user.

That's strange that you're not seeing the Authorization header in your app. You should. Is there something else after the authservice stripping it off? Like another Envoy filter? --------> No other envoy filter . envoy -->authservice-->istio policies-->backend

Im sure authservice is setting the authorization header with access token, since below istio group authorization policy is confirmed to be working.

apiVersion: "security.istio.io/v1beta1" kind: "AuthorizationPolicy" metadata: name: reqauthz-policy namespace: istio-system spec: selector: matchLabels: istio: ingressgateway action: ALLOW rules:

• to:
  • operation: methods: ["GET"] paths: ["/productpage"] when:
  • key: request.auth.claims[SSO_GROUPS] values: ["SP__SVC_APPS_ADMIN"]

I noticed when istio authentication/authorization policies are applied, the authorization header is not being forwarded to backend.

[cfryanr]

Hmm. What version of Istio are you using? I don't recall seeing that happen before.

cc @tylerschultz

[r-kotagudem]

istio 1.6

[r-kotagudem]

Hmm. What version of Istio are you using? I don't recall seeing that happen before.

cc @tylerschultz

istio 1.6 response

istio 1.4.5 response

[margocrawf]

Closing due to inactivity. Please reopen if you have more questions.