Nginx OpenIDC with Keycloak 2.5 - Redirect Loop #32

rkumark · 2017-01-19T13:39:42Z

Hello,

I have installed the lua-resty-openidc module in Nginx server and opensource keycloak server.

When I access any resource in Nginx it got redirect to Keycloak server for authentication. After authentication it redirect to Redirect URI and getting HTTP 500 server error. Am I missing something in the Redirect_Uri param?

http://nginxint.com:81/token?state=08621333464a7df9e995227744bc9d0a&code=grVpNleibVO_ogX5BhxEkgktuSEe83337xTrlvunkNo.458efbab-d1bf-4a98-89c0-9a958a3274b6

Returns HTTP 500 error.

Here is my opendic config.
access_by_lua '
local opts = {
-- the full redirect URI must be protected by this script and becomes:
-- ngx.var.scheme.."://"..ngx.var.http_host..opts.redirect_uri_path
-- unless the scheme is overridden using opts.redirect_uri_scheme or an X-Forwarded-Proto header in the incoming request
redirect_uri_path = "/token",
discovery = "http://keycloakint.com:8080/auth/realms/DCOS/.well-known/openid-configuration",
client_id = "NginxWS",
--client_secret = "<client_secret>"
--authorization_params = { hd="pingidentity.com" },
--scope = "openid email profile",
--iat_slack = 600,
--redirect_uri_scheme = "https",
--logout_path = "/logout",
--token_endpoint_auth_method = ["client_secret_basic"|"client_secret_post"],
--ssl_verify = "no"
}

zandbelt · 2017-01-19T14:21:09Z

looks like you need to configure a registered client secret that is not commented out

rkumark · 2017-01-19T15:13:46Z

I have the client secret, commented for testing. Here is my most recent config

access_by_lua '
local opts = {
-- the full redirect URI must be protected by this script and becomes:
-- ngx.var.scheme.."://"..ngx.var.http_host..opts.redirect_uri_path
-- unless the scheme is overridden using opts.redirect_uri_scheme or an X-Forwarded-Proto header in the incoming request
redirect_uri_path = "/mesos/",
discovery = "http://keycloakint.com/auth/realms/DCOS/.well-known/openid-configuration",
client_id = "NginxWS",
client_secret = "1f0b8205-aa23-48b6-9183-491b5c347218",
--authorization_params = { hd="pingidentity.com" },
scope = "openid email profile",
iat_slack = 600,
redirect_uri_scheme = "http",
--logout_path = "/logout",
-- token_endpoint_auth_method = ["client_secret_basic"|"client_secret_post"],
ssl_verify = "no"
}

rkumark · 2017-01-19T15:13:58Z

Thanks for the prompt response.

zandbelt · 2017-01-19T15:25:55Z

can you look into the error log and paste it?

rkumark · 2017-01-19T15:27:34Z

Here is the error log.

2017/01/19 15:27:08 [error] 32603#32603: *5 [lua] openidc.lua:294: authenticate(): state from argument: 0268b134ffd9713b0e7cbe5afe92712c does not match state restored from session: 2e02415f1c05c2e4866e146bb825f267, client: 134.132.52.220, server: ec2-54-209-213-133.compute-1.amazonaws.com, request: "GET /mesos/?state=0268b134ffd9713b0e7cbe5afe92712c&code=mc4ccfDtwnXFVtTqLLMzf0NLYk6M2C9eFJKIQVDEnL0.fbcfdf63-769f-431a-9afe-7d83b8d37ce8 HTTP/1.1", host: "ec2-54-209-213-133.compute-1.amazonaws.com:81"

zandbelt · 2017-01-19T15:31:55Z

Could it be that multiple parallel requests are going out at the same time?

rkumark · 2017-01-19T15:36:36Z

It goes in to infinite loop and fails.

What is Redirect_URI What value we need to use?
redirect_uri_path = "/redirect_uri",

Any possibility to join a web ex call to help on the lua module?

rkumark · 2017-01-19T15:39:37Z

I'm trying to proxy all the DCOS admin URLS via Nginx, but allow only authenticated users to DCOS admin urls.

zandbelt · 2017-01-19T16:33:49Z

The redirect URI is OK and correctly registered with the Provider or else you would not get to this error message; I believe multiple parallel request may be the issue here; can you provide the full log?

rkumark · 2017-01-19T16:54:33Z

Hello,

Here is the complete log with debug mode.
aa.zip

rkumark · 2017-01-19T17:09:32Z

From the log I see openidc module extracted the user id from token, not sure why its redirecting back to keycloak again and again.

2017/01/19 17:07:02 [debug] 1212#1212: *4 [lua] openidc.lua:274: openidc_call_userinfo_endpoint(): userinfo response: {"sub":"a1d3a221-2552-4e37-8e7e-5b44e8e376b6","name":"","preferred_username":"admin"}

zandbelt · 2017-01-19T18:18:42Z

I believe the error may be in your config: the redirect URI is a special case that is handled by lua-resty-openidc itself just be defining it; you should not try to access it directly from the browser; take a look at the sample configs that would show you protect a certain path "/" which is also the path that you access from the browser, not trying to hit the redirect URI directly.

There's room for documentation improvement indeed ;-)

rkumark · 2017-01-19T18:37:40Z

Can I leave the Redirect_URI blank? basically if I access example:

http://awsamazon.com/secured, After authentication redirect back to http://awsamazon.com/secured instead of http://awsamazon.com/redirect_uri

Second question, I would like to protect everything at the root example

http://awsamazon.com/ Lets protect everything under /

zandbelt · 2017-01-19T18:43:10Z

then protect "/" with your access_by_lua statement and use /secured as the redirect_uri_path setting, similar to the sample from the README here: https://github.com/pingidentity/lua-resty-openidc#sample-configuration-for-google-signin

but you can't serve real content on /secured then anymore, that's why you'd typically use a redirect_uri_path like /redirect_uri or /secured/redirect_uri; it's a "vanity URL" that handles protocol messages, it cannot serve content

rkumark · 2017-01-19T18:54:42Z

Still having the issue, I have secured at root level, but it keep on redirecting back and forth until browser throws error. Changed redirect uri back to redirect_uri and access the website as
http://awsamazon.com/

example:
location / {
include nginxoidc.conf;

nginxoidc.conf
local opts = {
-- the full redirect URI must be protected by this script and becomes:
-- ngx.var.scheme.."://"..ngx.var.http_host..opts.redirect_uri_path
-- unless the scheme is overridden using opts.redirect_uri_scheme or an X-Forwarded-Proto header in the incoming request
redirect_uri_path = "/redirect_uri",
discovery = "http://ec2-54-209-213-133.compute-1.amazonaws.com:8080/auth/realms/DCOS/.well-known/openid-configuration",
client_id = "NginxWS",
client_secret = "secret",
authorization_params = { hd="amazonaws.com" },
scope = "openid email profile",
iat_slack = 600,
redirect_uri_scheme = "http",
--logout_path = "/logout",
-- token_endpoint_auth_method = ["client_secret_basic"|"client_secret_post"],
token_endpoint_auth_method = "client_secret_basic",
ssl_verify = "no"
}

zandbelt · 2017-01-19T18:56:58Z

What URL are you typing in in your browser that kickstarts all of this?

rkumark · 2017-01-19T19:36:06Z

This is URL I'm starting
http://awsamazon.com/ and redirect to
http://awsamazon.com:8080/auth for authentication then redirect to
http://awsamazon.com/redirect_uri redirect_URI then redirect back
to http://awsamazon.com again the whole cycle starts .

See the attached developer tool trace

zandbelt · 2017-01-19T19:46:37Z

It would be good to see the HTTP responses and see if and how the session cookie is set.

rkumark · 2017-01-19T19:57:45Z

I see different different session cookie for each subsequent request. Let me see I can attach the Fiddler trace.

rkumark · 2017-01-19T20:44:19Z

Here is the fiddler trace. From: Hans Zandbelt [mailto:[email protected]] Sent: Thursday, January 19, 2017 1:47 PM To: pingidentity/lua-resty-openidc Cc: Ravikumar Kanniappan; Author Subject: [EXTERNAL] Re: [pingidentity/lua-resty-openidc] Nginx OpenIDC with Keycloak 2.5 (#32) External Sender: Use caution with links/attachments. It would be good to see the HTTP responses and see if and how the session cookie is set. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_pingidentity_lua-2Dresty-2Dopenidc_issues_32-23issuecomment-2D273878405&d=DwMCaQ&c=PskvixtEUDK7wuWU-tIg6oKuGYBRbrMXk2FZvF0UfTo&r=svYRWWWBDI2KemeHuaYEdWKd_g2HyIrKC4bOgr4zN7jXlzJHHS7TXuONZ4Y90OMu&m=uQNOUqS4IgGkUFWVMxZqxMaSB53tsPRlrq2EQKgV1vE&s=rEEYTKxHRCx2NbYpQmag21p3RvWkXoSQ8_BoiB5QRcM&e=>, or mute the thread<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_notifications_unsubscribe-2Dauth_AYDmwqyDNRNuI2BCBNwzBYDeFiII1K4gks5rT72dgaJpZM4LoHo3&d=DwMCaQ&c=PskvixtEUDK7wuWU-tIg6oKuGYBRbrMXk2FZvF0UfTo&r=svYRWWWBDI2KemeHuaYEdWKd_g2HyIrKC4bOgr4zN7jXlzJHHS7TXuONZ4Y90OMu&m=uQNOUqS4IgGkUFWVMxZqxMaSB53tsPRlrq2EQKgV1vE&s=H6DbU6WJXn7HH6OLRb1qVSy9CUIMVkEBWE4JbTIY-ww&e=>.

…

---------------------------------------------------------------------- This e-mail, including any attached files, may contain confidential and privileged information for the sole use of the intended recipient. Any review, use, distribution, or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive information for the intended recipient), please contact the sender by reply e-mail and delete all copies of this message.

zandbelt · 2017-01-19T21:15:15Z

I don't see the fiddler trace but you may be running in to an SSL issue with lua-resty-session; could you try the suggestion from bungle/lua-resty-session#23 (comment), i.e. use:

set $session_check_ssi off;
set $session_secret 623q4hR325t36VsCD3g567922IC0073T;

rkumark · 2017-01-20T13:40:07Z

I added both the parameter still issue is not resolved
set $session_check_ssi off;
set $session_secret 623q4hR325t36VsCD3g567922IC0073T;
set $session_storage cookie;

access_by_lua '
local opts = {
-- the full redirect URI must be protected by this script and becomes:
-- ngx.var.scheme.."://"..ngx.var.http_host..opts.redirect_uri_path
-- unless the scheme is overridden using opts.redirect_uri_scheme or an X-Forwarded-Proto header in the incoming request
redirect_uri_path = "/redirect_uri",
discovery = "http://ec2-54-209-213-133.compute-1.amazonaws.com:8080/auth/realms/DCOS/.well-known/openid-configuration",
client_id = "NginxWS",
client_secret = "AAAAAAAAAAAAAAAAA",
authorization_params = { hd="amazonaws.com" },
scope = "openid email profile",
iat_slack = 600,
redirect_uri_scheme = "http",
--logout_path = "/logout",
-- token_endpoint_auth_method = ["client_secret_basic"|"client_secret_post"],
token_endpoint_auth_method = "client_secret_basic",
ssl_verify = "no"
}

rkumark · 2017-01-20T13:41:31Z

Fiddleroidctrace.zip
Uploaded the Fiddler trace in Zip file.

rkumark · 2017-01-20T13:46:33Z

The attached screenshot shows every request comes with new session cookie.

zandbelt · 2017-01-20T13:59:00Z

the crux seems to be here, after hitting the redirect URI with an authentication response that is correctly processed, the browser is redirected to the original URL with a session cookie:

GET http://ec2-54-209-213-133.compute-1.amazonaws.com/redirect_uri?state=c6b8c4499edfe583386c97ad748b698a&code=2h3Z7sEU7ynR77lr9Z_ClhqEuyGmWhh-vDL2ZsS8r5M.99036141-2add-4081-8443-7fe09501e015 HTTP/1.1
Host: ec2-54-209-213-133.compute-1.amazonaws.com
Proxy-Connection: keep-alive
Cache-Control: max-age=0
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/55.0.2883.87 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Referer: http://ec2-54-209-213-133.compute-1.amazonaws.com:8080/auth/realms/DCOS/protocol/openid-connect/auth?scope=openid%20email%20profile&client_id=NginxWS&hd=amazonaws.com&state=c6b8c4499edfe583386c97ad748b698a&nonce=a24749ecdd77e8ec0800ba272883e4f3&redirect_uri=http%3A%2F%2Fec2-54-209-213-133.compute-1.amazonaws.com%2Fredirect_uri&response_type=code
Accept-Encoding: gzip, deflate, sdch
Accept-Language: en-US,en;q=0.8
Cookie: session=zCfHM4YNQUiIXUtb3qwZiA..|1484861923|xR-s0p1gn_Si9nx5HbowLxjgOT7IPEu5w-nZh5iII3nSi08at9lnr2Zog6IwWvtuv_E7-5IcmNukxMUDIV3ibmGLqfNBgzqhV0i5bQGjFQVSVfy2rrVpdppIJLCEK129PGvi5a1TTXzTKs3t1-22gA..|c96RWVrvMwvMSUEMcVqmy9FA5kM.


HTTP/1.1 302 Moved Temporarily
Server: openresty/1.11.2.2
Date: Thu, 19 Jan 2017 20:38:51 GMT
Content-Type: text/html
Content-Length: 167
Location: /
Proxy-Connection: Keep-Alive
Connection: Keep-Alive
Set-Cookie: session=zCfHM4YNQUiIXUtb3qwZiA..|1484861931|ceImglsofgV0YXpSTR5Bkg4cNAFs6uozWEAbw2KTMOiWpLg-O7nQKDaQybz3JzsnfXgIZ584zlHo9kRy4MTh97w9cpcfeD5Mn2XEmR6oTLR9842NK2cv5NmdE2M5IF-pT48mQl0WGMAgFF8Dm0b0C0JNdIttiIlBm7MZi_LmOjc9MdgtDqk5HKXWQtmVuWZvAdKmGsQn0pXsrj5rlDlYR7cH5i3bQr_I8gw4EGP0s6MCmf19IlHO2BZNzH_1RzrNdFZGyICO1VkrNPHXFm9QkfI2rM7iBpfyCdW5A095V7RmJQ5paYldqFS23ISX8DmW6YnGjWR_x0ZpWAE8xGBLzgaj5QCJIiu2pI7XaZFy_y4i2EiBaWcDr4c3NJNAM1ypHY4MBS3i4zMVEHw8qLBZ1OBvvvYLrAgAmQ84DxDhgPeY-OjkUCXwVAwi1lxwxgZJaEIRnMI0RgLl8QIQLLJPM0v2ylfkVxey60HH7fjqKIbaGWYinuWPz4Elxh-pgaWXI10QcijMWxxJEKC_DIypjXZ0TeAlbZ8uQIah4dtZMMDA5pfe_hUUnVKEtB8n1Nx251Bh7ke8peZlo480baIBB1JpSW-3Y_Wm5jv_Nf-PqDMwzVCCs0L-rtUPGXVF_veTG_7GHMq5puJH-mruhXWsvu99OrVrslo1uuFsV7tbFXrwLB_HDRS6CT51bFTwl107-B16tcEbCJG6eLPypLjwcnU_8KxZQc0qWhsbZ03ROTAwmWqEUJWS2Cj8G1gsNotf6yoCHA6Ql10wtdkMeSrgMHIKLITX83Mnvn93vU_ZdWRuWp-JN7Llt6Vzmm8Zc44eGPETWnwxfXwBgpdqr6vx9pDwvzbk5QNze0GeX9dzq_V38jyEIlL5VwCXPWizNY7dQXMLoX24hx05pD-N69NFjHeM-x7TTTZ4TweRdAvpnSeteEDKOfjhCj9AGjRgaHWh5ncOMq-6odVXXxK8_YSA3i0qT-WamcMSsDBEKxCk1VtWpqRA2uYAjgh555T1CgSgUeils5DsYqaWis4BmotXAUGSlke6bAJPj3NGaHJgSvehEfB_h-S8kPWPi7EbKP2dX7gzBrh3QaHNd0WTkJkntbdiQUF-WduMOCNRKl65VQehCEdxAE0lZONLcbQ8T0pocs4t_UHqiXFlvG2hMK2zGxTO7E2z9IxQzd4F9u5mDOEK6-XDZd-ytxqLMN0dE641RVHgAhkzfiNTNd4pf-0zxjGaFVDaXMXyXZyRZLEdARqCyoaHqzv9x2-oRl7Am6TXNMOqffCeU0EGQS3RLy8ixOrkg2VosPCPk49P502ftaBj3gyKLLaaQ6h8GyTSj0Kl27Zo7qBUDV5ehGAPVGg2f4Dk5GAw7z7NrpXHfTuBOozaZcfENn9aRRbsbk3fNpwvbi2bU6ZFXGXMdUiZP0NlbWA8m4PD-TBFpSUnZmztS9AnViaL-zyjlUk9rLboyKgsSqj6n0eXNT8ww03_uvKtIq3Lr1jLm0COK9-9nZd4g91bDd_3slOwB_izNx_FPKC_EnMD-D_8iPWwyPD3gD6r6WEN2P7ofmiTnzIntOKjWCj7wowIbJdm8HLi8iZFf6WiR_su0jw_nth3U8KaUrfkGLKy93i0W7pVsJVDWYS4Y-NkZR5nLHwQvPLS0TbA4G6vUr2e5mcG06Kg3hzbH6fbKGV9IEro64G2o__XstOPMJjOUAvdTVms_8E7Gxc1EicRq8sIYB7kZ1F4PWYU894_UpgemS4YdlYdgris_NqODt8gDppGtjhcQNg-cgnURJ_XhI5U6ytO5cLl3VHNj5uwzD9IMiVQhhaB33JjH06ptkxJ6gRnECA5JNeaQF3nTo07lDW0RcUZdYqRbmcqWbq_bImQtda98vJBxAf3mOixZgZoerJ_HT6uUy1GNtZGS2PU2pTDl63YmswwsgyEqFGQ465zn_6Wme1yBHHXgjhCpuCJ_ppwU74l9O-qNbrWzBr9yjeQtIeg6_YdwMauaioVyWIu35CATUGJmixmd4USo1ALu40b902C2z--yiMnaWmObl1-tPUP5aNksoPZEkm9GncW7UvbscKIjxIj4KOWHtHoC21i_dG2_l-Np88aLBwNMUDoqkEmj8N1ExyCcWDwWcoSs2PzP8V9SGiN6wXeOQIyc6QJUE900PpTgUoilsLTANzoKk5bGgPNv8arf-75ElxhSHYb_filev7bZ13hbGZLwP0_p8Yk50t3FsTotf4GJr3wYu_-EJ_LwiAT09FmkPCiE5UG7LNx2caZyo2RhS8UDnKU1A8GzainbWKFp5iLd-I_bfFYv4ruuA4YMCRNoMKxbGcwS9SRaP2iHy0u2SxlX_G9VXnRgALUIbVhCHdhXVRWy483Lhl-AXUzihl9T132tCLh4_7Tca6HMtlL26XpXV7-LB5e3qvO3o8j-JC6XUNsHXs30NHky_zKY6iU8_iqSPiogcjEmsGxji08W03CnCjJNYAyjWeAQN_-nYPTFiyZhI6M_1H6VfG1efM1U102kbFOmsbvrcq4fUhUjuMJfg0u019XoJx_04IvTGFgjCSxK224Hb9RLzqy-b_ZtsL-mO2BQyNtkkVsHQuXulIGNmL6xi98FQxv42yi7YCfOHbBLaneYK0IfLHuakmM63jUhjXIxCCS3mqma1pib3YEVhTZBF8OuvM3tur2GEIe1hsBc3mHAgFAi5XSuQinfWQrv_Aypvyyr96vVYCJsRs3rRpbqSeK2RdfwlEEcmIjN3wLS73Df_6GmQNE0AJhl8uHbY7MJUN49Fvxl9wiKe5slCW85e0MOjIAMMCcwCssKZD-72N5glaWPmGyOVWKAO2xRAO5K5-IxFT-2HCu2iPwWv_H6oUTTKfMifVDNgdvioaS-4feyDNJVcJmAEpGWpdPbqP56LdLtAsIG-nnHasXS5AnwhyuOeUYi4ASnukWpHy6-ETcwBQllUtDnjRcZrSDT5bAEmLVH43aWxsKLxNzkPO5ciwGt2KsmHxT1HjaR0gb2ronaLmVx4hKwqPckKKg19F9d7_xsUqiQ2wCuw6thrL2WkTRXcyMvaY53UyyGs9IK9fKqs7F-pB2FcN4cFZ-0cR2_w2KBeQcaCRDclR3fxZqC824qZPC6aO-odzc3q1Psx3XRfwyU5Yn0SgN9AXhLHfT2ujJXidS_h1usucb5q0iggjIwxJ8BhN-9psQVKeaOigNJyhMNHIwuAZjVPyy64McVGNceRkWDgI-AY6FJODKMCArYw6khLoBigi_1PV9CP1PO6NeyE_-q7M6I9qUZUEcZCNyiapzVfw2Z1NgkSd_uO0rhkVLRnebnX3_lrgeaX9ttQ27_1JynKSigQfT-TqFao1Xwq4hS-s_u5B__GZp1GE6XgZwIpnDDTKduEa1eL3XAfl835n996HtVZRzeIWLhckjuKp37_GMTFetoQ0yFsW-CcbGxFbMOkJCSE_WLWSX6y3NJTAOVLdNlFywI_hk3RLDP0-CiP2deWF-On5PqV-g76nxI_J9S0eGsQ89RUnaX2TT7tpaFztmInfupzbv9uysSYLDpc-chtBRoHHGOADOxBcZFHXWgQ-EwHJNBjteU4hBvnkvebGVsbbC0W7doiZdT0wSjfxP-qGS7ElvLdB96LyRzpzyv39a-1OsdRYZyT8AjjaXxxVrNPOt3KhbUwZx26uQE9FzVk_ZLaw7L245JtOmlEAwEWCFx3CEwBaKBFYAV-9iCY84qy_JGqBO1-GHMTdXtzhdT4s-coNFWRJBNtrs-kAv7Y_qyC0zCFFE2YNqBNcNcNurjhGibMLz1MvxwpY0iVzN5LsylhfqFCX3XdG6wWF-DKvK3FbG84KcLrr5V-russA1gVuvx1DIpafxsWm__03Tx9Qz-36Qj8lsKDv7EMsJzSSSvWrLCsgJCxf0POcv0aRhn2EAyQT38Av4u9Ad-qFRLD-bK1dVzI0DQtzTLtlNSguS0niBaThAQgB_CL9avChsXqzgBRXokNxeS9Cow-c4svt2NC0iNhs8tgaiRhvYgkwQZhQHcRWrn5_lA8mPetM1gIg6NraYq8PJ4a3zNX_QTt5nn6MRZ-WlQPPqE6OFIfU3xoclXhhxP45oqqPczv53vt166arkGuWxt3-iXQg7COXQDWw8_KIS3k9vGY-KKTvv3Q48KI5s9OidPuw-vZqSfsf_kPoAzPmti1_LnTQfEQg-PmWm5k4BmUUDJ1jkNZkFdX9y2f5iE3esL1vkeuVHAsp55OoxJoQAFyWxl_maPMnWJjVa6LWCVjLk_82P7NQJyOFjfCo0yQL1EdF6wWoAlWvfX8RY0o44_cTVXeePyydfKBiU1D14rTHzeFrnzHoWO4CS2mVMz9jFsWTlDglAUpTFRso6xGSfYxOq41ytk_nktavtwzjAhb_lViiKOMkqGp4GyAz-JflnVX4EPGu4iBOilKx0IqVjpAkY6jEQFXtqJBZhi5ijtHW9l9oazAWtJlDDUeYTDJeOSNxdKhVzdjX0Q87s82DBQIBMk_PiBYAZjFjU1AnI2FKnn2i4gns153ZqrV-OXKITboXhoQcjq6Snu7xOO0YwdMVosLt7DK3f5G5wrYjGtCuJ_Z9lS3w6ZJD6RReTdt20-p-57OLoh61Dr_AcvwXrn_9FYNuNYqz1KuasJVBtwx7mssGiv7JFwKEtIVl8aAyc63L7VSKGQcBj9LCCXWzbTLdPJ0N0hHlOu2E70-fe1aD2ekQn5WWBr7LRxKIMQQulwjmMBjUmPT-nfPwrjh6_9pA8w1jXmUg.|x4_ecnYTaazUOAhQCPoJf8Bp3i8.; Path=/; SameSite=Lax; HttpOnly

but then the next request is:

GET http://ec2-54-209-213-133.compute-1.amazonaws.com/ HTTP/1.1
Host: ec2-54-209-213-133.compute-1.amazonaws.com
Proxy-Connection: keep-alive
Cache-Control: max-age=0
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/55.0.2883.87 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Referer: http://ec2-54-209-213-133.compute-1.amazonaws.com:8080/auth/realms/DCOS/protocol/openid-connect/auth?scope=openid%20email%20profile&client_id=NginxWS&hd=amazonaws.com&state=c6b8c4499edfe583386c97ad748b698a&nonce=a24749ecdd77e8ec0800ba272883e4f3&redirect_uri=http%3A%2F%2Fec2-54-209-213-133.compute-1.amazonaws.com%2Fredirect_uri&response_type=code
Accept-Encoding: gzip, deflate, sdch
Accept-Language: en-US,en;q=0.8
Cookie: session=zCfHM4YNQUiIXUtb3qwZiA..|1484861923|xR-s0p1gn_Si9nx5HbowLxjgOT7IPEu5w-nZh5iII3nSi08at9lnr2Zog6IwWvtuv_E7-5IcmNukxMUDIV3ibmGLqfNBgzqhV0i5bQGjFQVSVfy2rrVpdppIJLCEK129PGvi5a1TTXzTKs3t1-22gA..|c96RWVrvMwvMSUEMcVqmy9FA5kM.

which still uses the old cookie value rather than the one from the Set-Cookie response header that was just served

I believe the size of the Set-Cookie header may just be too long since it exceeds 4096 bytes. Can you try a server-side caching mechanism such as memcache, https://github.com/bungle/lua-resty-session#memcache-storage-adapter?

rkumark · 2017-01-20T14:33:59Z

Thanks very much!!! You are 100% correct it was Cookie size issue. Luckily IE 11 able to accept more than 4K Cookie we tested in IT it works. unfortunately Firefox and Chrome are strict on Cookie size. Bottom-line the issue is around cookie size, I'm experimenting to reduce the cookie size using memcachce.

zandbelt · 2017-01-20T14:43:46Z

Cool; that's probably worth a warning somewhere in code or docs.

You could also try and reduce the information that Keycloak produces and that needs to be stored in the session.

zandbelt · 2017-01-21T19:42:27Z

added a Wiki page with a FAQ on this topic here: https://github.com/pingidentity/lua-resty-openidc/wiki#why-does-my-browser-get-in-to-a-redirect-loop

rkumark · 2017-01-23T13:34:40Z

Thanks for adding the FAQ. it definitely help others.

1zg12 · 2020-07-09T10:04:25Z

Seems like I am facing the same issue even though I have been using latest lua-resty-session.

The problem is if I am protecting one location, and redirect to another, it worked

the code is like

    location /test {

access_by_lua_block {

  local opts = {
    discovery = "http://keycloak:8080/keycloak/auth/xxxx/.well-known/openid-configuration",
    redirect_uri_path = "/",
   ....
    }

However, if I am trying to protect all locations, by moving the access_by_lua block before all locations.

  server {
access_by_lua_block {

  local opts = {
    discovery = "http://keycloak:8080/keycloak/auth/xxxx/.well-known/openid-configuration",
    redirect_uri_path = "/",
   ....
    }

location / {
...

it will get into the infinite loop:

zandbelt closed this as completed Jan 20, 2017

zandbelt changed the title ~~Nginx OpenIDC with Keycloak 2.5~~ Nginx OpenIDC with Keycloak 2.5 - Redirect Loop Jan 21, 2017

xurxofp mentioned this issue Mar 30, 2020

Redirect Loop with lua-resty-session 3.X #323

Closed

1zg12 mentioned this issue Jul 17, 2020

infinite redirects after authentication #343

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Nginx OpenIDC with Keycloak 2.5 - Redirect Loop #32

Nginx OpenIDC with Keycloak 2.5 - Redirect Loop #32

rkumark commented Jan 19, 2017

zandbelt commented Jan 19, 2017

rkumark commented Jan 19, 2017

rkumark commented Jan 19, 2017

zandbelt commented Jan 19, 2017

rkumark commented Jan 19, 2017

zandbelt commented Jan 19, 2017

rkumark commented Jan 19, 2017

rkumark commented Jan 19, 2017

zandbelt commented Jan 19, 2017

rkumark commented Jan 19, 2017

rkumark commented Jan 19, 2017

zandbelt commented Jan 19, 2017

rkumark commented Jan 19, 2017

zandbelt commented Jan 19, 2017 •

edited

Loading

rkumark commented Jan 19, 2017

zandbelt commented Jan 19, 2017

rkumark commented Jan 19, 2017

zandbelt commented Jan 19, 2017

rkumark commented Jan 19, 2017

rkumark commented Jan 19, 2017 via email

zandbelt commented Jan 19, 2017

rkumark commented Jan 20, 2017

rkumark commented Jan 20, 2017

rkumark commented Jan 20, 2017

zandbelt commented Jan 20, 2017

rkumark commented Jan 20, 2017

zandbelt commented Jan 20, 2017

zandbelt commented Jan 21, 2017

rkumark commented Jan 23, 2017

1zg12 commented Jul 9, 2020 •

edited

Loading

Nginx OpenIDC with Keycloak 2.5 - Redirect Loop #32

Nginx OpenIDC with Keycloak 2.5 - Redirect Loop #32

Comments

rkumark commented Jan 19, 2017

zandbelt commented Jan 19, 2017

rkumark commented Jan 19, 2017

rkumark commented Jan 19, 2017

zandbelt commented Jan 19, 2017

rkumark commented Jan 19, 2017

zandbelt commented Jan 19, 2017

rkumark commented Jan 19, 2017

rkumark commented Jan 19, 2017

zandbelt commented Jan 19, 2017

rkumark commented Jan 19, 2017

rkumark commented Jan 19, 2017

zandbelt commented Jan 19, 2017

rkumark commented Jan 19, 2017

zandbelt commented Jan 19, 2017 • edited Loading

rkumark commented Jan 19, 2017

zandbelt commented Jan 19, 2017

rkumark commented Jan 19, 2017

zandbelt commented Jan 19, 2017

rkumark commented Jan 19, 2017

rkumark commented Jan 19, 2017 via email

zandbelt commented Jan 19, 2017

rkumark commented Jan 20, 2017

rkumark commented Jan 20, 2017

rkumark commented Jan 20, 2017

zandbelt commented Jan 20, 2017

rkumark commented Jan 20, 2017

zandbelt commented Jan 20, 2017

zandbelt commented Jan 21, 2017

rkumark commented Jan 23, 2017

1zg12 commented Jul 9, 2020 • edited Loading

zandbelt commented Jan 19, 2017 •

edited

Loading

1zg12 commented Jul 9, 2020 •

edited

Loading