Skip to content

infinite redirects after authentication #343

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
1zg12 opened this issue Jul 17, 2020 · 4 comments
Closed

infinite redirects after authentication #343

1zg12 opened this issue Jul 17, 2020 · 4 comments

Comments

@1zg12
Copy link

1zg12 commented Jul 17, 2020

For this code snippet:

    location /test {

      access_by_lua_block {

        local opts = {
          discovery = "http://keycloak/...../.well-known/openid-configuration",
          redirect_uri_path = "/test",
          accept_none_alg = true,
          client_id = "xxxx",
          client_secret = "xxxxx",
          use_nonce = true,
          revoke_tokens_on_logout = true,
        }

        local res, err, url, session = require("resty.openidc").authenticate(opts)

        if err or not res then
        ngx.status = 403
        ngx.say(err and err or "no access_token provided")
        ngx.exit(ngx.HTTP_FORBIDDEN)
        end
      }
      default_type text/html;
      content_by_lua 'ngx.say("<p>hello, world here from test</p>")';
    }

When first time the location http://localhost/test is reached, it will direct to keycloak for authentication as configured.

Once it's authenticated, I am expecting it to come to /test, however, this time it found the session already authenticated, hence move on to print out "hello, world here from test".

However, instead, there was an infinite redirect after keycloak authentication.

Note: this sounds like a similar issue to #32 , however, I have already the updated lua-resty-session version
lua-resty-session (using 3.6-1)

Environment
  • lua-resty-openidc version: lua-resty-openidc 1.7.2-1
  • OpenID Connect provider: Keycloak
Expected behaviour

Once it's authenticated, I am expecting it to come to /test, however, this time it found the session already authenticated, hence move on to print out "hello, world here from test".

Did I miss anything?

Actual behaviour

However, instead, there was an infinite redirect after keycloak authentication.

Minimized example

Minimal, complete configuration that reproduces the behavior.

    location /test {

      access_by_lua_block {

        local opts = {
          discovery = "http://keycloak/...../.well-known/openid-configuration",
          redirect_uri_path = "/test",
          accept_none_alg = true,
          client_id = "xxxx",
          client_secret = "xxxxx",
          use_nonce = true,
          revoke_tokens_on_logout = true,
        }

        local res, err, url, session = require("resty.openidc").authenticate(opts)

        if err or not res then
        ngx.status = 403
        ngx.say(err and err or "no access_token provided")
        ngx.exit(ngx.HTTP_FORBIDDEN)
        end
      }
      default_type text/html;
      content_by_lua 'ngx.say("<p>hello, world here from test</p>")';
    }
Configuration and NGINX server log files

Config and logs for the minimized example, possibly provided as attachments.

@bodewig
Copy link
Collaborator

bodewig commented Jul 24, 2020

I'm not really sure things work as expected if your redirect_uri and the location are the same.

Without a server log all I can do is guess.

@1zg12
Copy link
Author

1zg12 commented Jul 27, 2020

I was trying to protect the location (/test here), maybe I have missed anything, what should be the proper way to protect the location?
Basically I would it directed to keycloak if not authenticated, otherwise, straight to the location.

@bodewig
Copy link
Collaborator

bodewig commented Jul 27, 2020

The redirect_uri is not where your request should end up once the user is authenticated but rather a URI that is part of the OpenID Connect flow and is visited during authentication. You need to cover both, the location you want to protect and the redirect_uri with authenticate. Most of the time the location you want to protect is more than a single resource but rather like a path prefix and you make the redirect_uri something that shares the same prefix.

In your case you could use redirect_uri_path = "/test/redirect_uri" and configure your OpenID Connect Provider to use that for your client. Then you should see a redirect coming from your OIDC Provider to /test/redirect_urifollowed by another redirect to/test` if authentication succeeds.

@1zg12
Copy link
Author

1zg12 commented Jul 28, 2020

thanks, @bodewig, I think I was confused by the redirect part earlier. Thanks for the clarification. I am closing the issue here.

@1zg12 1zg12 closed this as completed Jul 28, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants