Error: invalid_request Mismatching redirect URI.

[alexschroeter]

To reproduce:

When I try to connect via tailscale I assume I have to choose the "Arkitekt Server" via the tailscale IP. So I set "adress of your host" to \<tailscale IP>:8000 and "use".

Afterwards the Server is found and I can connect via "Login with ...." which brings me to the above mentioned error from the following url http://<Tailscale IP>:8000/o/authorize/?client_id=snfoinosinefsef&scopes=read%20write&response_type=code&redirect_uri=http%3A%2F%2F<Tailscale IP>%3A8010%2Fcallback&code_challenge=cT474bxpTkgBEvnW_F3EruJmRTqoMr6xIAGr8lSiEpc&code_challenge_method=S256

[jhnnsrs]

Hi Alex,

Ah the Redirect URI mismatch, I guess this will be a common problem and might really need a) more documentation b) a workaround.

The mismatch in redirect uri stems from the fact that you are using the web version to connect to an Arkitekt instance that is running on a remote server. By default the authentication via Oauth2 requires that redirect_uris are preconfigured when setting up the client (otherwise a harmful app could pose as the client and steal the auth-token). This is done in the lok.yaml config. You would need to add the tailscale ip into the allowed redirect uris.

- client_id: CLIENT_ID
  client_secret: CLIENT_SECRET
  client_type: public
  grant_type: authorization-code
  identifier: github.io.jhnnsrs.orkestrator
  name: orkestrator
  redirect_uris:
    - http://127.0.0.1/
    - http://127.0.0.1/callback
    - http://localhost:8010/callback
    - http://localhost:8010/
    - http://<TAILSCALE_UP>:8010/callback #this line here
  scopes:
    - read
    - write
  tenant: admin
  version: latest
  token: 293j40239j4023023n039j30sdofins3n09nw30d9n203nf03fsdfseoinsoeinfosein

This is one of the reasons why i recommend the orkestrator app, as here the redirection is pointing to the loopback address, were we temporarily spawn a server.

Alternatively i could imaging that we include some logic in the "redirect_uri_validator" that would automatically allow redirects to the same host name of the server (but vary ports). I would put this in the dangerous category however. But it would increase the easy of configuration when using the web site.

I am a bit conflicted about this however, as browsers are getting more and more locked down on accessing local network resources anyway (thanks Google...). Is there a reason why you would prefer the website approach?

[alexschroeter]

Well, I use all the interfaces you provide but the issue happens with the web interface. However, I think that the web interface is also one of the most important interfaces because it lowers the burden of entry to basically zero.

What you are saying makes sense but I kind of expected the redirect_uris to be set by the "Advertise" interface, meaning if I advertise to it, I expect to get connections from there.

[jhnnsrs]

Hi Alex,

Understandable confusion. That's one of the hurdles of developing with containers because the docker based containers just like lok are not aware of the outside network interfaces (so that I could automate that process). On the other Hand oauth2 (the spec) is immensely strict about non loopback redirect_uris.

There are two strategies that I could implement however:

1. Implement the Redirect Uri validator inside lok to always accept redirect uris on the same host (but different port) that lok is being reached on, and have this as a dangerous setting in the config but on by default?

2. Let the user on SETUP with konstruktor choose which network interfaces the service will be able to accept requests from. This brings the added benefit of restricting the allowed_hosts in django on setup. But also brings another source of potential configuration errors.

It is important to note however that some features of the website (such as visualizing images through zart) will not be functional when accessing through a network anyways because of mixed content concerns (encryption features on a http site). This is why I am pushing hard for the desktop client.

Hope that explains a few things.

On Tue, 28 Nov 2023, 09:16 Alexander Wilhelmi, @.***> wrote:

Well, I use all the interfaces you provide but the issue happens with the web interface.

What you are saying makes sense but I kind of expected the redirect_uris to be set by the "Advertise" interface, meaning if I advertise to it, I expect to get connections from there.

— Reply to this email directly, view it on GitHub https://github.com/jhnnsrs/lok-server/issues/2#issuecomment-1829310226, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAZLIELLM75EV6MGCBAT42LYGWMVLAVCNFSM6AAAAAA74MCYVSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQMRZGMYTAMRSGY . You are receiving this because you commented.Message ID: @.***>

[jhnnsrs]

An Autoconfiguration mode for websites is now implemented in lok-server-next. Which allows Websites to configure their own redirect uris on initial connection.

This should solve this issue.