Running on local development


I’m facing problem with local development stack when all the services run in docker with docker-compose
The services are bellow:

  • hydra
  • consent-login handler (go)
  • OAuth2 client (go)
  • resource server (not relevant for question)

My problem with OAuth2 client.
I’m using “” package to perform Authorization Code flow.
To initialize the oidc config this package provide oidc.NewProvider method which get the issuer url as parameter. In local development environment it is something like

Everything is working fine if i run the client application on the local computer but from docker container the address cannot be used to access the Hydra Public endpoint, and provider cannot download all .well-known data and failed to initialize itself.

In case of dockerized environment i the client app have to use internal address of hydra public api, but in this case all urls in client will point to internal address of public api, which is not accessible in browser. If the issuer of oidc.Provider will nor match to URLS_SELF_ISSUER of hydra, the provider also will fail to initialize.

I tried to run the oauth clien in docker with network_mode=host, in this case the inside container will point to localhost of the machine, but in this case my oauth2 client not accessible from the browser.

I’m really confused with this setup.

I also understand that if hydra public api will be on real host, i will not be an issue, but how to start the local development stack in docker?

Docker does not use localhost. Please read about Docker Networking:

This is not an issue that can be solved with / is caused by ORY.

Thank you for fast response.

I understand that is not an issue of Hydra, i just asked the community :slight_smile:
I read the docker network manual and i not found the solution. Because it i’m here :slight_smile:

For now it is seems for me that each service wants to communicate with hydra public api via browser (redirect flows) must run on the local machine, which is hard to believe for me that community still not solved it for local development.

Another option is to to try to use some dns service for containers (just thinks).

Again, i’m not going to open issue, it is a forum. If i’ll find solution, i’ll share it here

1 Like

In Docker, if two containers share the same network, you can call them by name. In the docker compose example for Hydra the login app uses the hydra service name as the hostname:

aeneasr, thank you

The problem is not here.
On consumer i use “” package, then
provider, err := oidc.NewProvider(ctx, HYDRA_PUBLIC_URL)
Then the provider initialize the oauth client URLs by reading data from HYDRA_PUBLIC_URL/.wel-known/etc…
This HYDRA_PUBLIC_URL must match to URLS_SELF_ISSUER of Hydra because oidc.NewProvider verify it and returns error if it not match.
The OAuthCodeURL of oauth2.Config will contain now HYDRA_PUBLIC_URL used in initialization of provider.

If we run the consumer inside container, the HYDRA_PUBLIC_URL must be internal docker address, and OAuthCodeURL of oauth2.Config will be not accessible from the browser.

It means that in local dokerized development environment we must have HYDRA_PUBLIC_URL accessible by single address from container and from browser. It can be solved by DNS i guess, but it not cross platform solution.

I want to provide oauth-oidc full stack to other developers in docker-compose file which will run on every operating system and it seems to be not possible

It is normal that the HYDRA_PUBLIC_URL is exposed publicly. You can’t expose it only internally. If your go-oidc app runs in the same docker network, you need to use the public URL. Take a look at our 5 Minute Tutorial because we’re doing exactly that there.

In 5 minute tutorial your configure the oauth2.Config.Endpoint manually here. But i want to use oidc extensions of coreos to verify id tokens by them. And it builds the endpoint inside function NewProvider. This method takes the provider url and loads the info from ./well-known. Then i must have the public URL of hydra accessible from browser and from application in container at same address.

Again, it is not issue of Hydra. Just interesting case