Convert a curl OAuth2 token request to httr

Question

I am trying to access the domain.com.au api using r and httr. I can achieve this using an API key but not with OAuth2

The docs indicate that:

Obtaining an access token via Client Credentials Make a POST request to the https://auth.domain.com.au/v1/connect/token endpoint using your client_id and client_secret, along with the list of scopes that you require. See the API references for the list of scopes that are required for each endpoint. Attempting to use a scope that is not included in your plan will result in a 400 invalid_scope error. This request must be authenticated using basic authentication with the client_id and client_secret corresponding to a username and password respectively.

https://developer.domain.com.au/docs/v2/authentication/oauth/client-credentials-grant

The curl implementation is simply:

curl -X POST -u 'clientid:secret' -H "Content-Type: application/x-www-form-urlencoded" -d 'grant_type=client_credentials&scope=api_listings_read%20api_agencies_read' 'https://auth.domain.com.au/v1/connect/token'

which returns the token without any redirect.

However, I have been unable to translate this to the equivalent httr POST request to obtain the token. What I presently have is:

oep <- oauth_endpoint(base_url = "https://auth.domain.com.au/v1/connect/token", 
                      request = NULL, 
                      access = "access_token" )

myapp <- oauth_app("domain",
     key = "client_id_here",
     # The secret isn't secrete. A user still has to authenticate when redirected.
     secret = "secret_here"
  )

# Retrieve the token
token <- oauth2.0_token(oep, 
                    myapp, 
                    scope = "api_listings_read")

This unnecessarily redirects to an unknown page, which I close and then am returned to the console where I press escape to exit.

I am reviewing Converting cURL to httr in R but so far no luck in getting it to work.

Any help would be much appreciated.

Answer 1

I resolved the issue. It seems that the simplest solution is to include everything in the body per

r <- POST("https://auth.domain.com.au/v1/connect/token",
          config = list(),
          body = list(
            grant_type="client_credentials",
            client_id="myclientid",
            client_secret="mysecret",
            scope="api_suburbperformance_read"
          ),
          encode = "form"
)
warn_for_status(r)          
content(r)

$access_token
[1] "my_requested_token"

$expires_in
[1] 43200

$token_type
[1] "Bearer"

tok <- content(r)$access_token

rg <- GET("https://api.domain.com.au/v2/suburbPerformanceStatistics/NSW/Pyrmont/2009",
          add_headers("Content-Type"="application/x-www-form-urlencoded",
                      Accept="text/plain",
                      "Authorization"=paste("Bearer", tok)))

warn_for_status(rg)


content(rg)

$header
$header$suburb
[1] "Pyrmont"

$header$state
[1] "NSW"

$header$propertyCategory
[1] "House"


$series
$series$seriesInfo
$series$seriesInfo[[1]]
$series$seriesInfo[[1]]$year
[1] 2020

$series$seriesInfo[[1]]$month
[1] 2
 
etc. etc.

where form is shorthand for including Content-Type: application/x-www-form-urlencoded in the header.

I worked out thethat Accept="text/plain" should be included in the get request by going to the endpoint docs https://developer.domain.com.au/docs/v2/apis/pkg_properties_locations/references/suburbperformance_get_bynamedsuburb and following the "Try it out" instructions so that I could look at the curl command structure (note the -H part of the command below).

curl -X GET "https://api.domain.com.au/v2/suburbPerformanceStatistics/NSW/Pyrmont/2009?bedrooms=3&startingPeriodRelativeToCurrent=1&totalPeriods=4" -H "accept: text/plain" -H "Authorization: Bearer my_requested_token"

As a side point, as a beginner using httr, I will comment that the api does not seem particularly helpful for any situation beyond a routine or common use case. It goes way to far in abstracting low level details away from the user. A vignette to deal with non-standard cases such as this one would go a way to assist. Nevertheless, I admit that my comment might just arise from the frustration of having to spend a few hours on figuring out how to implement what should be a trivially simple process.

I will leave this in an unanswered state for a few days to see if anyone else can suggest a better alternative or shed some additional light.