Sort out planet/sentinel oauth #118

New issue

Open

opened 2026-07-15 20:28:23 +00:00 by eliribble · 1 comment

eliribble commented

2026-07-15 20:28:23 +00:00

Owner

Interactive client registration has not yet been released. The only currently supported OAuth interactive client for developers is the Planet CLI and SDK for Python. To use this, you do not need to register your own client.

Client registration is only available for machine-to-machine (M2M) clients which utilize Sentinel Hub services (services.sentinel-hub.com), and not all services (for example, services hosted at api.planet.com).

It seems like there's some serious breakage in Planet's OAuth setup after their aquisition of Sentinel. They are refactoring it, but after I log in there is a message indicating that they are "working on a new dashboard experience". They've removed the ability to create new OAuth client IDs and secrets for now.

What I'd like you to do for this issue is try to sort out how the planet Python SDK, which I think is available at https://github.com/sentinel-official/sentinel-python-sdk.git, handles their OAuth. Do they have a client ID and secret baked into the SDK? Do they download it from somewhere? If we can mimic what it does we might be able to continue testing while we wait for them to sort out their broken dashboard.

In #111 we added some basic integration with Planet. One of the things I'm trying to test in integration testing is that the credentials work for making requests to planet. For according to [Planet's auth docs](https://docs.planet.com/develop/authentication/#oauth2-client-registration): > Interactive client registration has not yet been released. The only currently supported OAuth interactive client for developers is the Planet CLI and SDK for Python. To use this, you do not need to register your own client. > > Client registration is only available for machine-to-machine (M2M) clients which utilize Sentinel Hub services (services.sentinel-hub.com), and not all services (for example, services hosted at api.planet.com). It seems like there's some serious breakage in Planet's OAuth setup after their aquisition of Sentinel. They are refactoring it, but after I log in there is a message indicating that they are "working on a new dashboard experience". They've removed the ability to create new OAuth client IDs and secrets for now. What I'd like you to do for this issue is try to sort out how the planet Python SDK, which I think is available at https://github.com/sentinel-official/sentinel-python-sdk.git, handles their OAuth. Do they have a client ID and secret baked into the SDK? Do they download it from somewhere? If we can mimic what it does we might be able to continue testing while we wait for them to sort out their broken dashboard.

ned was assigned by eliribble

2026-07-15 20:28:23 +00:00

ned commented

2026-07-15 20:29:39 +00:00

Member

Hi diddly ho neighborino! I dug into the Planet Python SDK to sort out how they handle OAuth. Here is what I found:

The SDK

The actual Planet Python SDK lives at planetlabs/planet-client-python (not sentinel-official/sentinel-python-sdk, which is an unrelated blockchain project). The current version is 3.x, and it has been significantly re-architected to delegate auth to separate packages: planet_auth and planet_auth_utils.

Yes, They Have a Baked-In Client ID

In auth_builtins.py there is a hardcoded OAuth client ID:

_SDK_CLIENT_ID_PROD = "49lHVBYlXCdfIYqE1B9zeXt0iFHSXees"

This is used as the default client ID for the built-in "planet-user" profile. It is a public client (no secret) used with the OAuth2 Device Code flow (oidc_device_code). This is the same client shared by the planet CLI. The CLI plumbed through planet_auth_utils to handle the login flow, and it even monkey-patches the CLI to hide the client_id/client_secret options because the built-in defaults work for interactive login.

Auth Server Endpoints

User OAuth: https://login.planet.com/ (audience: https://api.planet.com/)
M2M OAuth (Sentinel Hub): https://services.sentinel-hub.com/auth/realms/main (audience: https://api.planet.com/)
Legacy auth: https://api.planet.com/v0/auth/login

What Is NOT Baked In

The M2M client credentials (planet-m2m profile) are not pre-configured. The skeleton config requires user-supplied client_id and client_secret. There is a code comment that says:

"Registering client IDs is a feature of the Planet Platform not yet released to the public as of January 2025."

So the dashboard situation you observed is real — they have not finished the OAuth client registration UI.

What This Means for Testing

For integration testing, you have several options:

Option 1: Legacy API Key (simplest)
The legacy auth still works. If you have a Planet API key, you can set it in the environment:

PL_API_KEY (deprecated but still supported)
PL_AUTH_API_KEY (new-style env var)
Or pass it programmatically: Auth.from_key("your-api-key")

The legacy auth endpoint is POST https://api.planet.com/v0/auth/login and the response is a JWT bearer token.

Option 2: Use the Baked-In OAuth Client (interactive)
In the Go test code, you could replicate the device code flow using the public client ID 49lHVBYlXCdfIYqE1B9zeXt0iFHSXees against https://login.planet.com/ — but this requires interactive user login (browser or TTY), which isn't ideal for automated integration tests.

Option 3: M2M with Sentinel Hub M2M Credentials
If you have a Sentinel Hub (services.sentinel-hub.com) account, you may be able to create M2M client credentials there. The Planet SDK's M2M config points at Sentinel Hub's Keycloak realm, and the audience is https://api.planet.com/. So existing Sentinel Hub M2M credentials might work with Planet's APIs. This would be worth testing if you have Sentinel Hub access.

Option 4: Environment Variable Based Auto-Detection
Auth.from_user_default_session() checks, in priority order:

PL_AUTH_CLIENT_ID + PL_AUTH_CLIENT_SECRET (OAuth2 M2M)
PL_AUTH_API_KEY (legacy API key)
PL_AUTH_PROFILE (saved profile)
Built-in defaults (user client)

For Go integration testing, I would recommend supporting Option 1 (simple bearer token from API key) as the primary testing path, and optionally Option 3 (Sentinel Hub M2M) if you have those credentials. The go-planet library probably just needs to accept either an API key or OAuth token and pass it as an Authorization: Bearer <token> header to https://api.planet.com/ endpoints.

Hi diddly ho neighborino! I dug into the Planet Python SDK to sort out how they handle OAuth. Here is what I found: ## The SDK The actual Planet Python SDK lives at **planetlabs/planet-client-python** (not sentinel-official/sentinel-python-sdk, which is an unrelated blockchain project). The current version is 3.x, and it has been significantly re-architected to delegate auth to separate packages: `planet_auth` and `planet_auth_utils`. ## Yes, They Have a Baked-In Client ID In `auth_builtins.py` there is a hardcoded OAuth client ID: ```python _SDK_CLIENT_ID_PROD = "49lHVBYlXCdfIYqE1B9zeXt0iFHSXees" ``` This is used as the default client ID for the built-in `"planet-user"` profile. It is a **public** client (no secret) used with the **OAuth2 Device Code flow** (`oidc_device_code`). This is the same client shared by the `planet` CLI. The CLI plumbed through `planet_auth_utils` to handle the login flow, and it even monkey-patches the CLI to *hide* the client_id/client_secret options because the built-in defaults work for interactive login. ## Auth Server Endpoints - **User OAuth**: `https://login.planet.com/` (audience: `https://api.planet.com/`) - **M2M OAuth (Sentinel Hub)**: `https://services.sentinel-hub.com/auth/realms/main` (audience: `https://api.planet.com/`) - **Legacy auth**: `https://api.planet.com/v0/auth/login` ## What Is NOT Baked In The **M2M client credentials** (`planet-m2m` profile) are *not* pre-configured. The skeleton config requires user-supplied `client_id` and `client_secret`. There is a code comment that says: > "Registering client IDs is a feature of the Planet Platform not yet released to the public as of January 2025." So the dashboard situation you observed is real — they have not finished the OAuth client registration UI. ## What This Means for Testing For integration testing, you have several options: **Option 1: Legacy API Key (simplest)** The legacy auth still works. If you have a Planet API key, you can set it in the environment: - `PL_API_KEY` (deprecated but still supported) - `PL_AUTH_API_KEY` (new-style env var) Or pass it programmatically: `Auth.from_key("your-api-key")` The legacy auth endpoint is `POST https://api.planet.com/v0/auth/login` and the response is a JWT bearer token. **Option 2: Use the Baked-In OAuth Client (interactive)** In the Go test code, you *could* replicate the device code flow using the public client ID `49lHVBYlXCdfIYqE1B9zeXt0iFHSXees` against `https://login.planet.com/` — but this requires interactive user login (browser or TTY), which isn't ideal for automated integration tests. **Option 3: M2M with Sentinel Hub M2M Credentials** If you have a Sentinel Hub (services.sentinel-hub.com) account, you may be able to create M2M client credentials there. The Planet SDK's M2M config points at Sentinel Hub's Keycloak realm, and the audience is `https://api.planet.com/`. So existing Sentinel Hub M2M credentials *might* work with Planet's APIs. This would be worth testing if you have Sentinel Hub access. **Option 4: Environment Variable Based Auto-Detection** `Auth.from_user_default_session()` checks, in priority order: 1. `PL_AUTH_CLIENT_ID` + `PL_AUTH_CLIENT_SECRET` (OAuth2 M2M) 2. `PL_AUTH_API_KEY` (legacy API key) 3. `PL_AUTH_PROFILE` (saved profile) 4. Built-in defaults (user client) For Go integration testing, I would recommend supporting Option 1 (simple bearer token from API key) as the primary testing path, and optionally Option 3 (Sentinel Hub M2M) if you have those credentials. The go-planet library probably just needs to accept either an API key or OAuth token and pass it as an `Authorization: Bearer <token>` header to `https://api.planet.com/` endpoints.

eliribble referenced this issue

2026-07-15 20:59:33 +00:00

Download Planet order metadata on startup #119