Skip to content
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

Invalid Redirect URI - Nginx Proxy Manager & Authentik #333

Open
Starstrike opened this issue Oct 16, 2024 · 3 comments
Open

Invalid Redirect URI - Nginx Proxy Manager & Authentik #333

Starstrike opened this issue Oct 16, 2024 · 3 comments

Comments

@Starstrike
Copy link

I created an issue over on HA's Core repository for this issue but I'm not sure who would actually have to fix this.

home-assistant/core#128305 is the link to it. It has the information, screenshots, etc.

Basically, when going to ha.domain.tld, I get prompted by Authentik. I sign in. Then I get the screenshot showing the invalid redirect URI. If I then just try ha.domain.tld again after I authenticated, I can click Log In and get to the dashboard.

I'm not sure what I need to change or where to fix this or if its a bug with HA or this integration.

Hoping to find some direction here.

@alametti
Copy link

alametti commented Oct 27, 2024

I am having a similar issue as you describe. For example, navigating to https://my.hass.tld/some_uri works fine, but navigating to https://my.hass.tld/some_uri?external_auth=1 leads to an error (either Invalid redirect URI on mobile app enrolment, identical to your screenshot in the linked issue, or Unable to connect to Home Assistant in other situations). This causes issues for me in the Android app, but using a browser on mobile or desktop works fine.

I don't think it is a problem with this integration since external authentication works seamlessly everywhere except on the Android app, and even there, there are no obvious errors related to this integration (see debug log below).

Hopefully someone smarter than me figures out the issue with ?external_auth=1.

Debug log:

2024-10-27 00:04:16.177 DEBUG (MainThread) [custom_components.auth_header] <CIMultiDictProxy('X-authentik-username': '***', 'X-authentik-groups': '***', 'X-authentik-email': '***', 'X-authentik-name': '***', 'X-authentik-uid': '***', 'Connection': 'upgrade', 'Host': 'home-assistant', 'Content-Length': '127', 'sec-ch-ua-platform': '"Android"', 'User-Agent': 'Mozilla/5.0 (Linux; Android 12; Pixel 3 XL Build/SP1A.210812.016.C2; wv) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Chrome/129.0.6668.100 Mobile Safari/537.36 Home Assistant/2024.10.3-14058 (Android 12; Pixel 3 XL)', 'sec-ch-ua': '"Android WebView";v="129", "Not=A?Brand";v="8", "Chromium";v="129"', 'Content-Type': 'text/plain;charset=UTF-8', 'sec-ch-ua-mobile': '?1', 'Accept': '*/*', 'Origin': '***', 'x-requested-with': 'io.homeassistant.companion.android', 'sec-fetch-site': 'same-origin', 'sec-fetch-mode': 'cors', 'sec-fetch-dest': 'empty', 'Accept-Encoding': 'gzip, deflate, br, zstd', 'Accept-Language': '***', 'priority': 'u=1, i', 'Cookie': 'authentik_proxy_***')>
2024-10-27 00:04:16.177 DEBUG (MainThread) [custom_components.auth_header] Got actual IP 172.30.0.1
2024-10-27 00:04:16.177 DEBUG (MainThread) [custom_components.auth_header.headers] Validating access for IP: 172.30.0.1
2024-10-27 00:04:16.177 DEBUG (MainThread) [custom_components.auth_header.headers] Checking user: ***
2024-10-27 00:04:16.177 DEBUG (MainThread) [custom_components.auth_header.headers] Found username in credentials: ***
2024-10-27 00:04:16.178 DEBUG (MainThread) [custom_components.auth_header.headers] Username match found, finishing login flow

Configuration for hass-auth-header:

http:
    use_x_forwarded_for: true
    trusted_proxies:
        - 172.30.0.1 # This needs to be set to the IP of your reverse proxy
auth_header:
    # Optionally set this if you're not using authentik proxy or oauth2_proxy
    username_header: X-authentik-username
    # Optionally set this if you don't want to bypass the login prompt
    # allow_bypass_login: false
    # Optionally enable debug mode to see the headers Home-Assistant gets
    debug: true
# Optionally, if something is not working right, add this block below to get more information
logger:
    default: info
    logs:
        custom_components.auth_header: debug

Edit: for now, I am using an alternate subdomain without proxy authentication for mobile devices as described here

@Starstrike
Copy link
Author

I am having a similar issue as you describe. For example, navigating to https://my.hass.tld/some_uri works fine, but navigating to https://my.hass.tld/some_uri?external_auth=1 leads to an error (either Invalid redirect URI on mobile app enrolment, identical to your screenshot in the linked issue, or Unable to connect to Home Assistant in other situations). This causes issues for me in the Android app, but using a browser on mobile or desktop works fine.

I don't think it is a problem with this integration since external authentication works seamlessly everywhere except on the Android app, and even there, there are no obvious errors related to this integration (see debug log below).

Hopefully someone smarter than me figures out the issue with ?external_auth=1.

Debug log:

2024-10-27 00:04:16.177 DEBUG (MainThread) [custom_components.auth_header] <CIMultiDictProxy('X-authentik-username': '***', 'X-authentik-groups': '***', 'X-authentik-email': '***', 'X-authentik-name': '***', 'X-authentik-uid': '***', 'Connection': 'upgrade', 'Host': 'home-assistant', 'Content-Length': '127', 'sec-ch-ua-platform': '"Android"', 'User-Agent': 'Mozilla/5.0 (Linux; Android 12; Pixel 3 XL Build/SP1A.210812.016.C2; wv) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Chrome/129.0.6668.100 Mobile Safari/537.36 Home Assistant/2024.10.3-14058 (Android 12; Pixel 3 XL)', 'sec-ch-ua': '"Android WebView";v="129", "Not=A?Brand";v="8", "Chromium";v="129"', 'Content-Type': 'text/plain;charset=UTF-8', 'sec-ch-ua-mobile': '?1', 'Accept': '*/*', 'Origin': '***', 'x-requested-with': 'io.homeassistant.companion.android', 'sec-fetch-site': 'same-origin', 'sec-fetch-mode': 'cors', 'sec-fetch-dest': 'empty', 'Accept-Encoding': 'gzip, deflate, br, zstd', 'Accept-Language': '***', 'priority': 'u=1, i', 'Cookie': 'authentik_proxy_***')>
2024-10-27 00:04:16.177 DEBUG (MainThread) [custom_components.auth_header] Got actual IP 172.30.0.1
2024-10-27 00:04:16.177 DEBUG (MainThread) [custom_components.auth_header.headers] Validating access for IP: 172.30.0.1
2024-10-27 00:04:16.177 DEBUG (MainThread) [custom_components.auth_header.headers] Checking user: ***
2024-10-27 00:04:16.177 DEBUG (MainThread) [custom_components.auth_header.headers] Found username in credentials: ***
2024-10-27 00:04:16.178 DEBUG (MainThread) [custom_components.auth_header.headers] Username match found, finishing login flow

Configuration for hass-auth-header:

http:
    use_x_forwarded_for: true
    trusted_proxies:
        - 172.30.0.1 # This needs to be set to the IP of your reverse proxy
auth_header:
    # Optionally set this if you're not using authentik proxy or oauth2_proxy
    username_header: X-authentik-username
    # Optionally set this if you don't want to bypass the login prompt
    # allow_bypass_login: false
    # Optionally enable debug mode to see the headers Home-Assistant gets
    debug: true
# Optionally, if something is not working right, add this block below to get more information
logger:
    default: info
    logs:
        custom_components.auth_header: debug

Edit: for now, I am using an alternate subdomain without proxy authentication for mobile devices as described here

Nice idea with just using a separate subdomain for mobile. Hopefully someone will look into this at some point, likely on the HA side, to see why the redirect URI doesn't work properly.

@m33ts4k0z
Copy link

m33ts4k0z commented Nov 9, 2024

Well I think I figured it out.

The problem here was not the external_auth=1 but rather the /auth/authorize endpoint.

More specifically, when the outpost completed the authentication, it redirected to that endpoint but for some reason it stripped down all parameters from the original request. (I am using an external outpost since the HA installation is not at the same location as the Authentik server). Sonnet helped me narrow down the issue and I was ultimately able to constantly reproduce it by opening i.ex. http://[IP]/auth/authorize in the web browser.

I am not that sure if the reason of the missing parameters is Authentik or something strange taking place between the many redirections so I came up with this approach that Sonnet helped turn it into a working config. In my case, this is placed in the location / block in an Nginx Proxy Manager host:

# Detect platform and set redirect for Android
if ($http_user_agent ~ "Home Assistant.*Android") {
    set $auth_redirect "1";
}
if ($request_uri = "/auth/authorize") {
    set $auth_redirect "${auth_redirect}1";
}
if ($auth_redirect = "11") {
    return 302 $scheme://$host/auth/authorize?response_type=code&client_id=https://home-assistant.io/android&redirect_uri=homeassistant://auth-callback;
}

# Detect platform and set redirect for iOS
if ($http_user_agent ~ "Home Assistant.*iOS") {
    set $ios_redirect "1";
}
if ($request_uri = "/auth/authorize") {
    set $ios_redirect "${ios_redirect}1";
}
if ($ios_redirect = "11") {
    return 302 $scheme://$host/auth/authorize?response_type=code&client_id=https://home-assistant.io/iOS&redirect_uri=homeassistant://auth-callback;
}

This looks a bit dirty but I have a quite complex setup and so far nothing seems broken after this change. This works with both Android and iOS. I tried it with the latest version (2024.10.3-full). It might need some fine tuning but it is a good start point and definetely better than totally skipping SSO authentication by choosing a dual domain setup.

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

3 participants