OAuth redirects for preview environments

Questions and Answers
1

We use Google OAuth for accessing our app. Google requires a redirect URI, and that URI cannot include a wildcard. Do you have any advice about how I would set that up for preview environments?

This article from Release suggests that they have a solution where there is a pool of URLs that the preview environments can use, but I don’t see that here. They also suggest and OAuth proxy, which I suppose I could build with a bit of work. Any ideas appreciated, thanks!

2

Hi @aubrey , thanks for pointing this and proposing the solution provided by Release (which I admittedly find very elegant). Indeed, we don’t have such option right now but I can see with our product team what we can do. Providing a pool of oAuth callback endpoints is definitely a good one and easy enough to be implemented.

In the meantime, I can recommend a temporary solutions that will work perfectly fine. Do you have the list of services where you need to configure oAuth callbacks?

I put @a_carrano and @Julien_Dan in cc.

3

Thanks @rophilogene, Google is really the only one that’s important to our workflow.

4

FWIW, I think the other nice thing is that it means the preview environments would all automatically be provisioned with a URL on our domain. In any case, thanks!

5

Hi @aubrey ,

It’s possible to customize URLs - cf this link

I’m checking to provide a complete tutorial of something you can put in place to address this. Quick question: how many Preview URLs do you think you would have in parallel?

Romaric.

6

@rophilogene gotcha, thanks! I saw that article but was a little confused about whether it would automatically set up things for each new preview environment that gets created. I’m almost ready to start creating them, when I do I’ll give it a try.

I can’t imagine we’d have more than 10 or so preview environments going at a time, but of course that would grow as the team gets bigger.

7

Got it @aubrey :pray:

BTW, I’m discussing with the team to provide something similar to the Release Handles that is a nice feature and would definitely help in the oauth case with preview.

I’ll keep you posted

8

I did manage to get this to work by creating an OAuth proxy. The steps for getting this working are:

  1. Create and host the proxy service so that it has a fixed URL (more on implementation later)
  2. When you kick off the OAuth process in the preview environment, set the redirect URL to that of the proxy service. Also, base64 encode the preview environment’s OAuth redirect URL and pass that as the state.
  3. When the redirect comes back to the proxy service, base64 decode the state and collect the params on the request. Redirect the browser to the URL from the state, and append the parameters you received to it.
  4. Now, the user will be redirected back to your preview environment and you will have the parameters you need to complete OAuth verification. When doing that, the only trick is that you have to use the redirect URL you provided to Google, which is the proxy one.

Here’s some code… for the proxy service, I wrote a really simple Sinatra app.

require "sinatra"

get "/auth/google-oauth-callback" do
  original_url = JSON.parse(Base64.decode64(params["state"]))["originalRedirectUrl"]

  uri = URI.parse(original_url)

  uri.query = URI.encode_www_form(params.except("state"))

  redirect(uri.to_s)
end

And a very simple Dockerfile for it.

FROM ruby:3.3.0

ADD Gemfile /app/
ADD Gemfile.lock /app/
WORKDIR /app

RUN bundle config set --local path 'vendor/bundle' && bundle install

COPY . /app

EXPOSE 3000

CMD ["bundle", "exec", "rackup", "-o", "0.0.0.0", "-p", "3000"]

I then created a project in Qovery, deployed this service to it, and attached a fixed URL to it. Then I set that fixed URL as an environment variable in my React app, VITE_GOOGLE_OAUTH_REDIRECT_PROXY_URL.

Now, in my React app where I kick off the OAuth process with Google I changed the args I pass to this:

      const oauthArgs = {
        appId: import.meta.env.VITE_GOOGLE_CLIENT_ID_WEB,
        redirectUrl: `${import.meta.env.VITE_GOOGLE_OAUTH_REDIRECT_PROXY_URL}/auth/google-oauth-callback`,
        responseType: "code",
        state: btoa(JSON.stringify({ originalRedirectUrl: redirectUrl }))
      };

This will result in the callback coming back to redirectUrl. There, I can process the parameters as usual, making sure to use the redirect URL to the proxy service when doing the validation.

Hopefully this’ll help.

1 Like
9

Thank you so much @aubrey - this is a really smart way of dealing with strict oauth domain configuration. I put @Julien_Dan and @a_carrano in cc - we might re-use what you have done (we’ll make sure to credits your work :pray: )

10

Please feel free to reuse, and LMK if you need any more info.

11

Hi all,
the way we use OAuth on Qovery preview envs is via Auth0 (which in turn can use Google) with callbacks of form “https://*.abc123.llvm.sh/api/auth/callback/auth0”

1 Like
12

Hi @adam.zielinski_any ,

Indeed, same for us - Auth0 acts as a proxy and we can use https://*.ourdomain.tld to allow preview authentications.

Thanks for sharing this tip as well :slight_smile:

14

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.