oAuth2 not working

[nautical-miles]

Hi, I'm trying to get HedgeDoc connectet via oAuth2 to keycloak or nextcloud. No matter what I try, HedgeDoc refuses to take the token. The browser is telling me something about internal server error. In the logs I can see an Internal OAuth Error: Failed to obtain access token with some Information in which module at what line the error occurs. At the end there is a line with the data comming from the browser. That data can be used to get the token. What I have tried so far:

• check if the settings in the environment variables are correct
• use Postman to see if a token is issued from keycloak or nextcloud
  1. Authorize to get a code
  2. Get a token with the code
  3. Get the userinfo with the token
• did a lengthy search in the internet about this error
• tried nextcloud instead of keycloak to see if it is working then -> it is not :-(
• tried different docker-compose files It seems to me that HedgeDoc fails at the first stage to authenticate. I hope it is only something wrong with my config even though I did it according to the documentation.

[SISheogorath]

Well, lets start with the basics: Can hedgedoc reach your IdP?

Many people run hedgedoc in combination with keycloak and other IdPs all over the place. So it's very very likely a config/setup issue.

[nautical-miles]

I think hedgedoc can reach the IdP. They are both in docker containers on the same host. If I understand it correctly the comunication between the two are done via the exposed ports (8080 for Keycloak and 3000 for HedgeDoc). Mentioning the network made me wonder and I set up a docker network where I put those containers in. Didn't make a change though; maybe also because the browser is still in the outside world. For the environment this is running in: I first started on a debian server where I had traefik as a reverse proxy running. After several days of trying to get it running I set up a test environment in WSL only hosting keycloak and HedgeDoc to make setup less complicated.

This is the environment section in the docker-compose file:

• CMD_OAUTH2_USER_PROFILE_URL=http://localhost:8080/auth/realms/anwendungen/protocol/openid-connect/userinfo
• CMD_OAUTH2_USER_PROFILE_USERNAME_ATTR=preferred_username
• CMD_OAUTH2_USER_PROFILE_DISPLAY_NAME_ATTR=name
• CMD_OAUTH2_USER_PROFILE_EMAIL_ATTR=email
• CMD_OAUTH2_TOKEN_URL=http://localhost:8080/auth/realms/anwendungen/protocol/openid-connect/token
• CMD_OAUTH2_AUTHORIZATION_URL=http://localhost:8080/auth/realms/anwendungen/protocol/openid-connect/auth
• CMD_OAUTH2_CLIENT_ID=hedgedoc
• CMD_OAUTH2_CLIENT_SECRET=KyzmaRwW0RL5jDxxxxxxxxxxxxxxxxxx
• CMD_OAUTH2_PROVIDERNAME=Keycloak
• CMD_OAUTH2_SCOPE=openid email profile

[SISheogorath]

Unless you run your containers with host network, localhost in the container is a different localhost than the host one.

And hedgedoc not being able to reach the IdP is a common problem for setups where the IdP and HedgeDoc run on the same host, due to how NAT and internal routing works.

[nautical-miles]

Unless you run your containers with host network, localhost in the container is a different localhost than the host one.

And hedgedoc not being able to reach the IdP is a common problem for setups where the IdP and HedgeDoc run on the same host, due to how NAT and internal routing works.

Got it. Docker is capsuling the network for each container. However, if I can reach both containers via a browser outside the docker environment, in this case also from a different pc, Hedgedock should be able to reach the IdP. Is this correct or am I missing something here?

[SISheogorath]

Nope, as I mentioned due to how NAT works it is possible that it doesn't work as expected. The external URL of your IDP should point to the external IP of your host and there have been often reported issues of contianer trying to communicate with the external IPs of hosts.

Usually this can be resolved by adding the external hostname as alias to your internal container that would handle the connection from outside (potentially a reverse proxy). This way, the containers communicate directly without trying to go through the host NAT and things should work fine.

[nautical-miles]

Seems that did the trick. Adding hostname: whatever to the docker-compose file solved the issue. I wonder what is going on in the background: No matter what I enter as a hostname (localhost, the real hostname or the domain visible from the internet) it is working now. I can even comment it out again and restart the container and it is still working. I leave this ticket open for a few days to see if what I entered in the file is correct...

Anyway, many thanks for your help.

[ErikMichelson]

We're glad that your problem could be solved and will therefore close this issue. In case there's something still not working properly in the same context, feel free to re-open this issue. Otherwise, you might want to take a look at the community forum.