wag icon indicating copy to clipboard operation
wag copied to clipboard

Browser Redirect to 404 After Successful OIDC Client Authorization

Open arjun-udaan opened this issue 1 year ago • 3 comments

I’m encountering an issue when setting up OIDC with Azure. After a successful client authorization, the browser redirects to https://domain.com/authorise/oidc?code=XXXXX but results in a 404 page not found error.

The logs from WAG only show the user registering with OIDC and do not indicate if the process is completed or if there’s an error:

2024/09/17 09:09:16 deauthed user:10.1.2.249 device, reason: session terminated
2024/09/17 09:09:40 user 10.1.2.249 registering with oidc

Configuration:

{
    "NumberProxies": 0,
    "Proxied": false,
    "HelpMail": "[email protected]",
    "Lockout": 5,
    "ExternalAddress": "domain.com",
    "MaxSessionLifetimeMinutes": 1440,
    "SessionInactivityTimeoutMinutes": 60,
    "ManagementUI": {
        "ListenAddress": "172.31.0.1:4433",
        "Enabled": true,
        "Debug": false
    },
    "Webserver": {
        "Public": {
            "ListenAddress": ":443",
            "CertPath": "/etc/letsencrypt/fullchain.pem",
            "KeyPath": "/etc/letsencrypt/privkey.pem"
        },
        "Tunnel": {
            "Port": "445"
        }
    },
    "Authenticators": {
        "Issuer": "IT",
        "Methods": [
            "oidc"
        ],
        "DomainURL": "https://domain.com",
        "OIDC": {
            "IssuerURL": "https://login.microsoftonline.com/tenant/oauth2/v2.0/authorize",
            "ClientSecret": "secret",
            "ClientID": "clientid",
            "GroupsClaimName": "groups"
        },
        "PAM": {
            "ServiceName": ""
        }
    },
    "Clustering": {
        "ClusterState": "new",
        "ETCDLogLevel": "error",
        "Witness": false,
        "TLSManagerListenURL": "https://172.31.0.1:3434"
    },
    "Wireguard": {
        "DevName": "wg0",
        "ListenPort": 5920,
        "PrivateKey": "key",
        "Address": "10.1.2.1/24",
        "MTU": 0,
        "ServerPersistentKeepAlive": 0
    },
    "DatabaseLocation": "devices.db",
    "Acls": {
        "Policies": {}
    }
}

Additional Observations:

  • The OIDC callback URL does not update once the service starts. Even after changing the web server port in the config, the callback URL continues to use the old port.

logs: 2024/09/17 09:30:44 Started control socket: /tmp/wag.sock **2024/09/17 09:30:44 OIDC callback: https://domain:8080/authorise/oidc** 2024/09/17 09:30:44 Connecting to OIDC provider: https://login.microsoftonline.com/tenant/v2.0 2024/09/17 09:30:44 Connected! 2024/09/17 09:30:44 Started listening: Tunnel Listener: 10.1.2.1:445 Public Listener: :443 2024/09/17 09:30:44 Started Managemnt UI: Listening: 172.31.0.1:4433

Any assistance in resolving this would be greatly appreciated.

arjun-udaan avatar Sep 17 '24 09:09 arjun-udaan

Hi there,

To take a stab in the dark I expect you've missed a trailing slash: https://domain.com/authorise/oidc?code=XXXXX should be https://domain.com/authorise/oidc/?code=XXXXX

NHAS avatar Sep 20 '24 00:09 NHAS

Thank you for responding back I did a quick test by adding a trailing / to the redirect URL, but this introduced a new error from Microsoft which kinda make sense

Sorry, but we’re having trouble signing you in.

AADSTS50011: The redirect URI 'https://domain/authorise/oidc' specified in the request does not match the redirect URIs configured for the application 'XXXXX'. Make sure the redirect URI sent in the request matches one added to your application in the Azure portal. Navigate to https://aka.ms/redirectUriMismatchError to learn more about how to fix this.
This error makes sense as the URL in the request does not match the one configured in the Azure portal.

From the WAG logs: OIDC callback URL: https://domain/authorise/oidc

arjun-udaan avatar Sep 20 '24 04:09 arjun-udaan

That looks like you haven't configured the new allowed url redirection in your azure tenancy with the new end slash.

NHAS avatar Sep 25 '24 10:09 NHAS

The error was after I have configured the URL redirection in the azure tenant,

the error says "The redirect URI 'https://domain/authorise/oidc' specified in the request does not match the redirect URIs configured for the application 'XXXXX'", as I have set 'https://domain/authorise/oidc/' which does not match.

I fell confused here, as this should have been a very simple process, but it seems I'm stuck for now.

arjun-udaan avatar Oct 07 '24 07:10 arjun-udaan

I think this is a configuration issue on your end so Im going to close this issue for now

NHAS avatar Oct 31 '24 12:10 NHAS

I'm trying to help my college, I don't know anything about this project, I don't know how all this is being used, but here is some ideas about what seems to be the issue:

As I understand, there is some code that acts as a HTTP client, right?

https://github.com/NHAS/wag/blob/6389c0fd6b227bbcda2e8bc400779b590daba8ce/internal/webserver/authenticators/oidc.go#L74

You might think that the path is going to be /authorise/oidc/, but actually the trailing slash is going to be removed, so the path will actually be /authorise/oidc.

As I understand, there is some code that is used to make handler on the server, right?

https://github.com/NHAS/wag/blob/6389c0fd6b227bbcda2e8bc400779b590daba8ce/internal/webserver/authenticators/authenticators.go#L137

As you can see, the callback is set on path with a trailing slash!

So, client is trying to reach /authorise/oidc, but there is no handler on the server side. Yes, I checked – http.ServeMux doesn't assume that path without trailing slash is the same one with a trailing slash.

One solution would be adding additional handler without a trailing slash like this:

mux.HandleFunc("/authorise/"+string(method), checkEnabled(handler, handler.AuthorisationAPI))

taai avatar Mar 13 '25 16:03 taai