OSDK oauth with dynamic subdomains

Ask the Community
,
1

I’m trying to get the OSDK oauth flow to work with arbitrary subdomains. For example, our application runs on some.app.domain, but I would also like to make it work on foo.some.app.domain and bar.some.app.domain. Since the application uses the OSDK, this means that the oauth flow should work on those domains. I can’t make this work, and am looking for any ideas that I can explore that might solve this. More details below on what I’ve already tried.

The issue is that Foundry only allows a fixed set of callback urls to be configured, and these need to be fixed string matches: no wildcards allowed, which means no dynamic subdomains or query parameters. I have asked Palantir but the dev team says no for “security” reasons.

I have tried redirecting to the root domain of our app after login, and storing the subdomain on the app side for a later redirect. However, the subdomain still isn’t authenticated after this, since it looks like the OSDK doesn’t use cookies (which can be valid on sudomains) but localStorage, which can’t be shared with subdomains.

Any ideas are welcome as I am currently out of them and stuck.

2

There is no workaround for this (for good security reasons).

You could automate the addition of redirect URIs to the Dev Console app or the underlying TPA. Would that be an option?

3

Thanks! Automation would be an option, the use case is preview urls for pull requests, so we could add an action when creating an PR to add the urls, and when closing it to remove them. Do you know if there are supported APIs for this?

I’m also curious about the security implications of allowing wildcard domains. Do you have a short explanation or a link to one?

4

We do have support in foundry-dev-tools to update regular TPAs, including the redirect_uri.

https://github.com/emdgroup/foundry-dev-tools/blob/main/libs/foundry-dev-tools/src/foundry_dev_tools/clients/multipass.py#L1061

I have never tested this with Developer Console Apps, which are a wrapper around regular TPAs. You could give it a try…

I realized we don’t have any GET endpoints to check the current state but here is the python code that you would need to add to the multipass.py:

    def api_get_third_party_application_installation(
            self,
            client_id: str,
    ) -> requests.Response:
        return self.api_request("GET", f"client-installations/{client_id}")

    def api_get_third_party_application(
            self,
            client_id: str,
    ) -> requests.Response:
        return self.api_request("GET", f"clients/{client_id}")

Regarding the security implications I think this thread has good opinions.

https://github.com/oauthjs/node-oauth2-server/issues/229

5

That looks promising! I’m able to get the client data through foundry_dev_tools, and an update call returns with a 200. However, in the Developer Console, the new callback uri isn’t shown. Retrieving it through the API does show it, until I update it through the UI, then it disappears.

I’m not sure what’s going wrong here. The Foundry UI seems to be using different (graphql) queries to retrieve and mutate the data. It doesn’t surface the data as saved through the REST API, but does seem to overwrite it. Any ideas what’s going on?

6

And is the login working with the added redirect_uri? (my assumption would be yes)

I am afraid the Dev Console app has it’s own persistence layer which is not updated when we update the TPA underneath (which is our own risk anyway).

I have asked Palantir PD for a REST API to manage Developer Console apps (to full migrate to them, as we manage thousands of TPAs through the code in foundry-dev-tools) but it seems it is not taking up as priority. Maybe you can +1 this through your channels?

7

I haven’t yet tested if it works as a redirect uri, since I got the feeling I was doing something wrong. I’m slightly uneasy about using the REST API to update something that can be overwritten by someone editing it in the dev console. We only have a single application, so for us this risk is real. I guess I could try to use the graphql query instead?

I’ll definitely try out if the added redirect url works and echo back here, and I’ll also reach out to Palantir and ask about supporting this use case better.

8

That’s a serious risk and I would also not take it.

You can use the graphql by sending the same User-Agent as the browser does. But at your own risk.