Invalid redirect parameter | HTTP 400 when starting Google sign_in

[omerxx]

Describe the bug
Upon calling the SSO service through the proxy, I'm redirected to the authenticator where I see this:

Tried changing the upstream, the scheme settings, the google credentials, the allowed URI, literally everything I could think of. Would really appreciate any response

To Reproduce
RUNNING ON AWS ECS:

My Proxy container:

FROM buzzfeed/sso
ARG client_id \
    client_secret \
    session_cookie_secret
ENV UPSTREAM_DEFAULT_EMAIL_DOMAINS="domain.co" \
    UPSTREAM_CONFIGFILE="/sso/upstream_configs.yml" \
    UPSTREAM_CLUSTER="tools-global" \
    PROVIDER_URL_EXTERNAL="https://sso-auth.domain.co" \
    CLIENT_ID=$client_id \
    CLIENT_SECRET=$client_secret \
    SESSION_COOKIE_SECRET=$session_cookie_secret \
    UPSTREAM_SCHEME=https \
    LOGGING_LEVEL=debug
COPY ./upstream_config.yml /sso/upstream_configs.yml
ENTRYPOINT ["/bin/sso-proxy"]

Authenticator:

FROM buzzfeed/sso
ARG client_id \
    client_secret \
    session_cookie_secret \
    session_key
ENV AUTHORIZE_EMAIL_DOMAINS=domain.co \
    AUTHORIZE_PROXY_DOMAINS=* \
    SERVER_HOST=sso-auth.domain.co \
    CLIENT_PROXY_ID=$client_id \
    CLIENT_PROXY_SECRET=$client_secret \
    SESSION_COOKIE_SECURE=false \
    SESSION_COOKIE_SECRET=$session_cookie_secret \
    SESSION_KEY=$session_key \
    PROVIDER_DOMAIN_CLIENT_ID=$client_id \
    PROVIDER_DOMAIN_CLIENT_SECRET=$client_secret \
    PROVIDER_DOMAIN_TYPE=google \
    PROVIDER_DOMAIN_SLUG=google
ENTRYPOINT ["/bin/sso-auth"]

Upstreams:

- service: snappass
  default:
    from: snappass.domain.co/
    to: https://secrets.domain.co/
- service: redis
  default:
    from: redis.domain.co
    to: redis.ecs.domain.local:6379/

Expected behavior
Being redirected to Google login screen like in the quickstart

Desktop (please complete the following information):

• OS: MacOS
• Browser Chrome / Safari / Brave

Additional context
I'm running on ECS Fargate and no matter what I've changed this fails to work.
I was able to reproduce locally with the quickstart when changing http scheme to https, I can only assume it is relevant but I just don't know.

[omerxx]

I found the solution by going through with the Google provider setup steps 3,4 - although they clearly state it is only relevant if a granularity of groups and users is required. Once I loaded credentials.json I was able to login.
Still, I cannot understand the reason for it not being able to function with just client_id and secret_id.

This project is really awesome, but it lacks clear documentation. Would be happy to help improve it if I can get a point of communication.

[Jusshersmith]

Hey @omerxx,

Thank you for submitting this, and I'm sorry for the difficulties you've faced; I appreciate you sticking with it and working through the problem though!

While I haven't yet found the time to dig into this, I wanted to respond and at least acknowledge this. We need to clarify whether it's the documentation that's incorrect or the logic -- I'm not convinced at this point that it isn't the logic itself, though it needs some further investigation either way.

Separately, I agree that parts of the documentation could benefit from some extra clarity! This is definitely something I'd like to invest some time in. Any contributions are welcome and appreciated as always 🙂

[omerxx]

@Jusshersmith I appreciate your response.
Not really sure either as this came down to trail and error.
Working on a blog post that will describe my real-life experience with implementing everything on ECS.
If I'll find time to incorporate a list of optional & mandatory configuration variables, I'll make sure to make a PR out of it.

Thanks again :)

[omerxx]

Hey @Jusshersmith just published my post helping ppl integrating the same way I did.
Hope it helps and maybe @buzzfeed-api finds something in it...
https://dev.to/omerxx/introduction-to-zero-trust-on-aws-ecs-fargate-38bl