Unsecured Protocol Error using localhost suffix


Hello everyone,

I am testing Hydra locally,

I have an identity provider service implementing login and consent flow, it interacts correctly with Hydra.
At the end of the flow, the final redirection, Hydra returns an error saying I am using an insecure protocol, which is the case, it also tells me I can use an unsecure protocol using localhost suffix in the URL.

“The request is missing a required parameter, includes an invalid parameter value, includes a parameter more than once, or is otherwise malformed” error=invalid_request hint="Redirect URL is using an insecure protocol, http is only allowed for hosts with suffix localhost, for example: http://myapp.localhost/."

My problem is I am using the exact URL the hint suggests and I have still the same error.

This is the performed request with the redirect_uri parameters (which is saved as `http://myapp.localhost/ in the database):

GET on /oauth2/auth?client_id=my-client&grant_type=authorization_code&scope=read&redirect_uri=http%3A%2F%2Fmyapp%2Elocahost%2F&response_type=code&state=thisisarandomstring`

Did I miss some Hydra configuration to allow correctly unsecure protocol or something else ?

Thanks for you help !


Please state the version you’re running


My bad, I am running the latest version 1.0.0-rc.6+oryOS.10 (using the docker image: oryd/hydra:v1.0.0-rc.6_oryOS.10)


Can you show your configuration? Including the way you’re starting hydra?


Of course, I am using docker-compose:

    image: oryd/hydra:v1.0.0-rc.6_oryOS.10
      - postgresd
      - hydra-migrate
      # Public port
      - 4444:4444
      # Admin port
      - 4445:4445
      # Port for hydra token user
      - 5555:5555
      serve all --dangerous-force-http
      - OAUTH2_ISSUER_URL=http://localhost:4444
      - OAUTH2_CONSENT_URL=http://localhost:3000/consent
      - OAUTH2_LOGIN_URL=http://localhost:3000/login
      - DATABASE_URL=postgres://hydra:[email protected]:5432/hydra?sslmode=disable
      - SYSTEM_SECRET=youReallyNeedToChangeThis
      - OIDC_SUBJECT_TYPES_SUPPORTED=public,pairwise
      - OIDC_SUBJECT_TYPE_PAIRWISE_SALT=youReallyNeedToChangeThis
    restart: unless-stopped

I have also a container for the sql server, sql migration, and the identity provider which are basically also a copy/paste of the official repo docker-compose.yml.

Logs after the start seems to reflect the configuration:

Attaching to identity-provider_hydra_1
hydra_1            | time="2019-03-25T12:05:05Z" level=info msg="Setting up tracing middleware"
hydra_1            | time="2019-03-25T12:05:05Z" level=info msg="No tracer configured - skipping tracing setup"
hydra_1            | time="2019-03-25T12:05:05Z" level=info msg="Connecting with postgres://*:*@postgresd:5432/hydra?sslmode=disable"
hydra_1            | Thank you for using ORY Hydra v1.0.0-rc.6+oryOS.10!
hydra_1            |
hydra_1            | Take security seriously and subscribe to the ORY Security Newsletter. Stay on top of new patches and security insights.
hydra_1            |
hydra_1            | >> Subscribe now: http://eepurl.com/di390P <<
hydra_1            | time="2019-03-25T12:05:05Z" level=info msg="Connected to SQL!"
hydra_1            | time="2019-03-25T12:05:05Z" level=warning msg="Could not parse login and consent request lifespan value (). Defaulting to 15m"
hydra_1            | time="2019-03-25T12:05:05Z" level=info msg="Setting up Prometheus middleware"
hydra_1            | time="2019-03-25T12:05:05Z" level=info msg="Setting up http server on :4445"
hydra_1            | time="2019-03-25T12:05:05Z" level=warning msg="HTTPS disabled. Never do this in production."
hydra_1            | time="2019-03-25T12:05:05Z" level=info msg="Setting up http server on :4444"
hydra_1            | time="2019-03-25T12:05:05Z" level=warning msg="HTTPS disabled. Never do this in production."


What’s the result of hydra clients get my-client?


Here is the basic configuration of my unique client:

docker-compose exec hydra hydra clients --endpoint http://localhost:4445 get my-client
	"client_id": "my-client",
	"grant_types": [
	"jwks": {},
	"redirect_uris": [
	"response_types": [
	"scope": "read",
	"subject_type": "public",
	"token_endpoint_auth_method": "client_secret_basic",
	"userinfo_signed_response_alg": "none"


Thank you for the trace! That does seem kind of strange, I’ll investigate.


The behaviour disappeared upgrading to version 8.


That was an easy fix! :smiley: