Programmatic user & API key creation for external service integration

[pcace]

Title: Programmatic user & API key creation for external service integration

I'm building an integration between a web platform and GeoNode, where I want to automatically mirror spatial data to GeoNode via the REST API. The basic workflow would be:

Create a user via POST /api/v2/users ← this works fine
Get an API key / access token for that user ← this is the problematic part
Upload datasets via POST /api/v2/uploads/upload on behalf of that user
Set permissions so only the owner can view
Give the user a WFS endpoint URL with their token embedded
The user should never log in to GeoNode – everything happens through my backend.

The problem is step 2: how do I get an OAuth2 access token programmatically? I explored a few options:

A) POST /o/token/ with grant_type=password
This returns unauthorized_client unless I manually add a new OAuth2 Application with authorization_grant_type=password. The default GeoServer app only supports authorization-code. Is there a setting (env var?) to auto-create such an app?

B) Django admin panel
I can create AccessToken objects manually, but that requires admin shell access – not viable for an automated deployment.

C) POST /api/v2/users response
The user creation endpoint doesn't return a token.

My question:
What is the recommended / intended way to programmatically issue an API key for a newly created user? Is there an existing endpoint I'm missing, a Django signal I should hook into, or a configuration flag to enable password-grant OAuth2?

I'd love to hear how others have solved this, and ideally contribute any missing piece back upstream.

As a base of discussion, i have created this branch on my for which acutally does exactly what i want:
master...pcace:geonode:feature/auto-create-api-token-on-user-creation
BUT, there are some problems:

• OAuth2 app creation in the signal handler – Application.objects.get_or_create() inside a post_save signal is unclean. Database objects should be created via migrations or management commands, not as a side effect of user creation.
• Token belongs to the wrong scope – The token is created for a dedicated "GeoNode API" app, not for the existing "GeoServer" app. That it still works for WFS is rather coincidental (the introspection validates any valid token).
• Naming of settings – DEFAULT_OAUTH_API_APPLICATION_CLIENT_ID in settings.py is not an established pattern. Other OAuth2 settings are named OAUTH2_CLIENT_ID, not DEFAULT_OAUTH_API_APPLICATION_CLIENT_ID.

[giohappy]

Hi @pcace thanks for raising the question.
This is an open point for discussion, and it requires taking a higher-level view of what an access token currently is in GeoNode.
As you will know, the token is a standard OAuth2 token that is issued for the GeoServer OAuth2 application. Its main purpose is to allow Geoserver to authenticate the GeoNode users. At the same time, GeoNode stresses this goal a bit and uses the token also for its own purposes, which is authenticating users for its API endpoints.

These tokens are created either through the Geoserver UI, when a user clicks the GeoNode login button (this is the standard OAuth2 flow) or by GeoNode, transparently, for new user sessions created in GeoNode.
The latter is already sort of an abuse of the token, outside standard flows, but it's fine. It's an internal model not exposed to other components, which is also why it's not exposed through an API.

Long story short, the current GeoNode tokens are not properly designed for dynamic issuing, rotation, and all the best practices around API keys.

This is to say that, in my opinion, we would need a brand new solution for API Key management that also allows restricting scopes and managing their lifecycle with a proper API, including letting users delete or refresh the keys.

This is not an answer yet, but I would move away from the current tokens in a new, dedicated direction. And for one more reason: the current tokens are mainly for Geoserver/GeoNode integration. Their model and usage could (and will) probably change during the next months, when the authentication with Geoserver 3 will require applying various changes to their auth service.