[OAuth] The state parameter is empty when "invalid_scope" error

Context

I have an user that only have permissions over some tables inside a schema. If I try to make a request to the OAuth service including any dataset for a table to which my user does not have permissions, I get an error response (as expected) but my state parameter is not properly preserved.

Current Result

When I execute the request:

https://<user>.carto.com/oauth2/authorize?scope=datasets:r:SCHEMA.TABLE_WITHOUT_PERMISSIONS&redirect_uri=http://example.com&state=MY_STATE&client_id=MY_CLIENT_ID&response_type=code

I get the following redirection (note the empty state value):

http://example.com?error=invalid_scope&error_description=Unsupported+scopes:+datasets:r:SCHEMA.TABLE_WITHOUT_PERMISSIONS&state=

Expected result

I was expecting to get the same provided state:

MY_REDIRECT_URI?error=invalid_scope&error_description=Unsupported+scopes:+datasets:r:SCHEMA.TABLE_WITHOUT_PERMISSIONS&state=MY_STATE

[alasarr]

PR created with the fix: https://github.com/CartoDB/cartodb/pull/15684

[martejpad]

@alasarr There’s no short answer for that. Let me explain (sorry for the long text).

The underlying problem is: right now there is no way of obtaining a token that has read permissions for all the datasets of a user.

The workaround we came up with for AENA was to ask the user. Before login, the user chooses from a list of airports he wants to access. With that information we form the scopes, and we do the login. However, we ended up with the problem described in this issue: if the user tries to access an airport he doesn’t have permissions for, the OAuth throws an “invalid scope” error, but the backend is not able to manage the redirection to the frontend as it does not include the state parameter. The main consequence is simply a bad UX.

A couple of weeks ago (long after this workaround was implemented) I had a chat with @alrocar and he explained there is a way to do a double login process that would enable to do what we want to do without asking the user. The process would be:

1. First login for scope datasets:metadata.
2. With the token obtained, access the list of datasets of the user calling api/v4/datasets.
3. Now that you know the list of datasets, do a second login including in the scopes all the datasets of the user.

We did not know this process was possible, otherwise we would have opted for this instead of asking the user.

A definite solution would be to have a “wildcard” option for the scopes, and be able to do something like datasets:r. @alrocar mentioned this has been in talks for a while, and in my opinion it’s a feature that will be valuable for many PS projects, present and future. It will also simplify the integration of CARTO’s OAuth.

In conclusion, if this issue is not fixed, we could:

1. Implement the workaround of the double login instead, but that means development efforts from our side.
2. Leave it as it is, this is, not managing the error and simply having bad UX, and wait for the datasets:r solution.