Privileged scopes not accessible - uber-api

We are integrating the Uber API into an app that is still in the development phase and not quite ready to go through the privileged scope request process. The API documentation states that "During development, your account (and any developer accounts you list on the dashboard) will be able to authorize these [privileged] scopes without whitelisting."
However, it seems that we are unable to access these privileged scopes at the moment, even just for development purposes. Can someone help us understand why this might be the case? We have put together a document with screenshots and commands to help illustrate the issue, which we can share via email if someone from the Uber API team is kindly able to help. Thanks!
Further information:
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
REQUEST:
https://sandbox-api.uber.com/v1.2/requests
-H ‘Accept-Language: en_US’
-H ‘Content-Type: application/json’
-H ‘Authorization: Bearer ’
Payload
{
"fare_id": "d30e732b8bba22c9cdc10513ee86380087cb4a6f89e37ad21ba2a39f3a1ba960",
"product_id": "a1111c8c-c720-46c3-8534-2fcdd730040d",
"start_latitude": 37.761492,
"start_longitude": -122.423941,
"end_latitude": 37.775393,
"end_longitude": -122.417546
}
RESPONSE:
Status: 401: Unauthorized
{
"message": "This endpoint requires at least one of the following scopes: request.delegate.tos_accept, request, request.delegate",
"code": "unauthorized"
}
As shown above the request API call is returning unauthorized status and appears to require Privileged Scope for accessing it.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

The issue is that you need to authorize the privilege scopes by enabling them for your app in the dev dashboard and then passing them during the oauth authorize stage.

Related

Facebook device/login returning access token but without the requested permissions

I am sending a request to the Facebook device/login API via curl using a shell script as documented in the Facebook Login for Devices page:
curl -i -X POST https://graph.facebook.com/v14.0/device/login -F 'access_token=${app_id}|${client_token}' -F 'scope=ads_management,business_management,instagram_basic,instagram_content_publish,pages_read_engagement,pages_show_list,public_profile'
(The app_id and client_token are properly filled in.)
I get back the response such as
{
"code": "f4ee7axxxxxxxxxxxxxxxxec4b8e28eb",
"user_code": "PXXXXXXQ",
"verification_uri": "https://www.facebook.com/device",
"expires_in": 420,
"interval": 5
}
In my browser, I open a fresh private page and go to https://www.facebook.com/device, log in, and enter the user_code (e.g. PXXXXXXQ), and it completes successfully.
I then "poll" device/login_status via this curl command:
curl -i -X POST https://graph.facebook.com/v14.0/device/login_status -F 'access_token=${app_id}|${client_token}' -F 'code=f4ee7axxxxxxxxxxxxxxxxec4b8e28eb'
and get back a response with an access token:
{
"access_token": "EAAKxxxxxxxxxxxxxxxxxxxxxuuu",
"data_access_expiration_time": 1663078272,
"expires_in": 5183984
}
I then put the access token into the Access Token Debugger and find that it only has the two basic permissions of pages_show_list and public_profile. The other permissions are not granted.
I'm assuming I do not have my app configured properly. So far, the Facebook support has punted on the question so I'm turning here for help. I have "Enable Login for Devices" as the API page says in Step 1. I have "Facebook Login", "App Events", and "Instagram Basic Display" in my "Products" list. I don't see any warnings or flags on any of the app's pages. My "Test User" is a real Facebook user listed as in a Tester roll in the app.
Ultimately I want to use the Instagram media API. As a simpler test of the access token, I was trying to use the {page_id}?fields=instagram_business_account as a test and it wasn't working. Some pages suggest disconnecting and reconnecting the Instagram user and other things but I think the problem originates with the access token not having sufficient permissions.
I have also tried just requesting the permissions needed for the {page_id} and got the same results.
What changes do I need to make to get an access token via the device/login API that has more than just pages_show_list and public_profile permissions?

Using the Actions REST API Outside of Google Assistant?

We currently have a Google Action that requires users to log into our system and our OAuth account linking flow successfully provides an access token for authenticating with our fulfillment backend. This works great when our Action makes queries within Google Assistant.
We're also interested in using the Google Actions REST API with own custom chatbot in our web app, our iOS app, and other app platforms, but when making requests of the Google Actions API outside of Google Assistant, we keep receiving 401 authentication error responses.
Is it possible to use the Google Actions REST API outside of the Google Assistant environment? If so, then would someone be able to tell us what we're missing in our REST API calls?
As an example, based on the Google Actions REST API documentation - https://developers.google.com/assistant/actions/api - if we include our valid OAuth access token via the "Authorization: Bearer" header when making a test Google Actions REST API call via the command line:
curl -X POST "https://actions.googleapis.com/v2/projects/[OUR PROJECT ID]:matchIntents" -H "Authorization: Bearer [OUR OAUTH ACCESS TOKEN]" -H "x-goog-user-project: [OUR PROJECT ID]" -H "User-Agent: [OUR APP PLATFORM/VERSION INFO]" -H "accept: application/json" -H "Content-Type: application/json" -d "{ \"query\": \"how much money do we owe\", \"locale\": \"en-US\"}"
We always get a 401 error response, no matter how we tweak the headers:
{
"error": {
"code": 401,
"message": "Request had invalid authentication credentials. Expected OAuth 2 access token, login cookie or other valid authentication credential. See https://developers.google.com/identity/sign-in/web/devconsole-project.",
"status": "UNAUTHENTICATED"
}
}
We've searched extensively online for any troubleshooting hints, but we have not found any answers to what we might be doing wrong here. Is there something missing from our API calls -OR- is the Google Actions REST API simply not accessible outside of the Google Assistant environment? Any help would be much appreciated.
The Actions on Google / Actions Builder platform is not designed to be used outside of the Google Assistant environment. If you want a way to programmatically match intents or call an API, you should use Dialogflow and their APIs.

Why does the PayPal API not recognize my client id and secret

The Paypal API doesn't recognize my Client ID and Secret I got from https://developer.paypal.com/developer/applications/
I wanted to include a server side checkout according to this tutorial https://developer.paypal.com/docs/archive/checkout/how-to/server-integration/
When I do the request to https://api-m.paypal.com/v1/payments/payment I always get a 401 Error with the message "Authentication failed due to invalid authentication credentials or a missing Authorization header.".
I checked multiple times if my credentials were correctly included into the request. I also tested the endpoint in my server environment and as well via Postman.
I also tried the route https://api-m.sandbox.paypal.com/v1/oauth2/token to exchange my credentials with an access token and got the same problem.
I also tried to create multiple Sandbox and Live Accounts and always got the same error.
Has anyone an idea what the problem could be?
There are two separate issues here.
You first need to use /v1/oauth2/token to obtain an access token, and then use that access token to call any of the other actual APIs.
The credentials you obtain from PayPal Developer will be for either "Sandbox", or "Live". Make sure you choose the correct tab (sandbox, for development). Sandbox credentials will only work for api-m.sandbox.paypal.com , and Live credentials will only work for api-m.paypal.com . The two environments are completely separate.
If you still have issues, post the SANDBOX client ID and secret you are using, and the full request and response to the api-m.sandbox.paypal.com endpoint. There should be a PayPal-Debug-Id in any error response, in the headers if nowhere else.

Authentication with Openshift API running on IBM cloud failed with 401 unauthorized error

I'm trying to build some application to manage my OpenShift cluster on IBM cloud and the first step is to authenticate against both IBM cloud and the OpenShift cluster.
https://cloud.ibm.com/docs/openshift?topic=openshift-cs_api_install#kube_api
I followed the steps describe in the above link, and successfully obtained all the tokens including 'access_token', 'id_token' and 'refresh_token'. Among them the 'id_token' is supposed to be used to authenticate against the OpenShift API.
With the access_token I can visit IBM cloud API successfully, like obtaining account, cluster information.
However, when I use the id_token to call OpenShift API, it failed with the following error. It happened even for the '/version' api, which can be accessed without providing a bearer token.
{
"kind": "Status",
"apiVersion": "v1",
"metadata": {},
"status": "Failure",
"message": "Unauthorized",
"reason": "Unauthorized",
"code": 401
}
I can verify that my account have correct service roles assigned as described here, and I can see corresponding roles with 'ibm' prefix assigned in OpenShift web portal as well.
Can anyone please verify that the instructions in the first link above is still valid or have any clue about what might have been wrong?
[Update]
To help troubleshooting, I paste a sample of tokens here, this is what I get for the step3 in the 'Working with your cluster by using the Kubernetes API' section in the link, it is a bit lengthy:
{
"access_token": "eyJraWQiOiIyMDIxMDIxOTE4MzUiLCJhbGciOiJSUzI1NiJ9.eyJpYW1faWQiOiJJQk1pZC0yNzAwMDU1WERHIiwiaWQiOiJJQk1pZC0yNzAwMDU1WERHIiwicmVhbG1pZCI6IklCTWlkIiwianRpIjoiMDY1OWI5MjktMDE1Zi00MDg0LTgwZWMtYmFhZjBhYTBkNDQ4IiwiaWRlbnRpZmllciI6IjI3MDAwNTVYREciLCJnaXZlbl9uYW1lIjoi6Iic5a2QIiwiZmFtaWx5X25hbWUiOiLpmYgiLCJuYW1lIjoi6Iic5a2QIOmZiCIsImVtYWlsIjoicmFmb3VsQDE2My5jb20iLCJzdWIiOiJjaHN6Y2hlbkBjbi5pYm0uY29tIiwiYXV0aG4iOnsic3ViIjoiY2hzemNoZW5AY24uaWJtLmNvbSIsImlhbV9pZCI6IklCTWlkLTI3MDAwNTVYREciLCJuYW1lIjoi6Iic5a2QIOmZiCIsImdpdmVuX25hbWUiOiLoiJzlrZAiLCJmYW1pbHlfbmFtZSI6IumZiCIsImVtYWlsIjoicmFmb3VsQDE2My5jb20ifSwiYWNjb3VudCI6eyJ2YWxpZCI6dHJ1ZSwiYnNzIjoiOWM5NzI1YmQxM2VhNDU2Nzg4YWMwZWU3OGQ4NjQ2ZTEiLCJpbXNfdXNlcl9pZCI6Ijg4NzM1NzYiLCJmcm96ZW4iOnRydWUsImltcyI6IjM0NjU1MiJ9LCJpYXQiOjE2MTQyNTU5ODYsImV4cCI6MTYxNDI1OTU4NiwiaXNzIjoiaHR0cHM6Ly9pYW0uY2xvdWQuaWJtLmNvbS9pZGVudGl0eSIsImdyYW50X3R5cGUiOiJ1cm46aWJtOnBhcmFtczpvYXV0aDpncmFudC10eXBlOmFwaWtleSIsInNjb3BlIjoiaWJtIG9wZW5pZCBjb250YWluZXJzLWt1YmVybmV0ZXMiLCJjbGllbnRfaWQiOiJrdWJlIiwiYWNyIjoxLCJhbXIiOlsicHdkIl0sInN1Yl85Yzk3MjViZDEzZWE0NTY3ODhhYzBlZTc4ZDg2NDZlMSI6ImNoc3pjaGVuQGNuLmlibS5jb20iLCJpYW1faWRfOWM5NzI1YmQxM2VhNDU2Nzg4YWMwZWU3OGQ4NjQ2ZTEiOiJJQk1pZC0yNzAwMDU1WERHIiwicmVhbG1lZF9zdWJfOWM5NzI1YmQxM2VhNDU2Nzg4YWMwZWU3OGQ4NjQ2ZTEiOiJJQk1pZC1jaHN6Y2hlbkBjbi5pYm0uY29tIn0.Rm3F0UKz9Aq3-1xXMmkFi0UkENIvQUkRo6qhtWaG3LKBH5HHsZbAQeJUhKqXYbI643nj2ssDP2U50BVv-6zbpfmyVncP5Z5Dmi620mi2QesduRQaH1XlC-l7KuF3uT0hJ_9FSD-0Wqi5ph0pkKxHJ-BmLkHC-4F0NByiUtwIpwyTpthuzwC251XZsQ9Ya8gzCxHB9DFb3tzOF3cupVVZmc2mMJbv4JuTSnP00H5rOT4yIzeI0Lqm6LhDpMRJ4P8glmIxmU6fag42P94pFNf3jEzIZGl49NINiWXlKbAleij3vSouobtYvrBmxWQF4KpuwKPEI-bMf1zpsHPYBHWidg",
"id_token": "eyJraWQiOiIyMDIxMDIxOTE4MzUiLCJhbGciOiJSUzI1NiJ9.eyJpYW1faWQiOiJJQk1pZC0yNzAwMDU1WERHIiwiaXNzIjoiaHR0cHM6Ly9pYW0uY2xvdWQuaWJtLmNvbS9pZGVudGl0eSIsInN1YiI6ImNoc3pjaGVuQGNuLmlibS5jb20iLCJhdWQiOiJrdWJlIiwiZ2l2ZW5fbmFtZSI6IuiInOWtkCIsImZhbWlseV9uYW1lIjoi6ZmIIiwibmFtZSI6IuiInOWtkCDpmYgiLCJlbWFpbCI6InJhZm91bEAxNjMuY29tIiwiZXhwIjoxNjE0MjU5NTg2LCJzY29wZSI6ImlibSBvcGVuaWQgY29udGFpbmVycy1rdWJlcm5ldGVzIiwiaWF0IjoxNjE0MjU1OTg2LCJhdXRobiI6eyJzdWIiOiJjaHN6Y2hlbkBjbi5pYm0uY29tIiwiaWFtX2lkIjoiSUJNaWQtMjcwMDA1NVhERyIsIm5hbWUiOiLoiJzlrZAg6ZmIIiwiZ2l2ZW5fbmFtZSI6IuiInOWtkCIsImZhbWlseV9uYW1lIjoi6ZmIIiwiZW1haWwiOiJyYWZvdWxAMTYzLmNvbSJ9LCJzdWJfOWM5NzI1YmQxM2VhNDU2Nzg4YWMwZWU3OGQ4NjQ2ZTEiOiJjaHN6Y2hlbkBjbi5pYm0uY29tIiwiaWFtX2lkXzljOTcyNWJkMTNlYTQ1Njc4OGFjMGVlNzhkODY0NmUxIjoiSUJNaWQtMjcwMDA1NVhERyIsInJlYWxtZWRfc3ViXzljOTcyNWJkMTNlYTQ1Njc4OGFjMGVlNzhkODY0NmUxIjoiSUJNaWQtY2hzemNoZW5AY24uaWJtLmNvbSIsImdyb3Vwc185Yzk3MjViZDEzZWE0NTY3ODhhYzBlZTc4ZDg2NDZlMSI6WyJkZXZvcHMtYWRtaW4tdnBuLW9ubHkiLCJkZXZvcHMtZGVmYXVsdC12cG4tb25seSIsIklQV0MgQWRtaW4iXX0.Y42KUJRGgZA9OV164GAKSF0W5rRNGf3x32YXrAo5UvKhpOK0k4r_hwZU5BZhI2y3t-UqM7lNOIxexpft2Zmc9ApQ6BlVN-iN1jcfBzxmrUPMObpc1-vDrAc9Sq84J8nYzy1Rk32ydFHeb3V2iDhJn14_NOnXwhuz9EFkSg0uUZHugTAPx5A-VcdrehceX0yOqAOfX5EzTtmHoI8-JQbfNt8pyBSJs8Eoag7_mtfNgx13bP_-M8W7tltCSHhPEO46gUurPFkvasHggConPQ_oBw3ANAvY8tDfivrGmdiR2Q-uc4SnFAjOgC77YskDLskBcOeehhBvxwDkyufztzqM6w",
"refresh_token": "OKDsw87zCujUXCmb4LZ3-DFQN7lUa0ejdqau_fL3Voms7M7DaKYgO07gZW29VQbcwdGc3z8jrQjjf_4gOutKyRCZ6LyEiSEKTZQ6Kovwqji02Puxu3fzIFB9f8-a1hMlkTtP4u32_FTCmOZA6ARvzxEyRX36CtQEzSVz-zVMsvPxdgyztUEWPTtvbr7aPn4eq209OzTGzTyPCBFR-N0gVp2tKLbIrGmyi_vgC-6xLRvR2nWGJsUwaaBjXwvICeCBY3qRJ90VyP1krBSHa72f1XJWpvLnBWHN8qo1dfPknHvknlEZ3kMUA87KZkynkgiVifhRq90oNAKYHhKJ4XRs2tyz05zW5a8qEhgoIVsslUzDLLNU1btRF_3g587dKckPzEav3BgQlCik4im8gIC74HFGZOz4P7z9QKLJHQY7ElDillH8pLRjW8Dx0yZvn8Yo5rSqJSj0zUmJxNZMUNEpF_DTQhHCePNOWu1_1q4o5cIb_Mv-mGMMVwrVUsJYUyaeV9O5cWl58eWlHQxS3SbuAjsBrzfSdcrIyFe5aQViyL_sL1-o54xFrMJPC3prPD25TS4vUOwAy7tc9r1AGZG00YUGaxPwzKcOWBI4DqksIiEKPOtcm3k0y24TuwRPa0AK-9jfYAzkx3rciBYGKbq1WOFjX-p6LH67ayxVUJcQcjSMe-35LZnsHQtc0VOxNHjJKdJiHsKOYEDY1Nz0k4zGZr1EZ6j7w4tLpBXP9ThC8hReiihWDmld9lzFdLwKZPF7jl4u03a2WQZ6j-wMHvLtOBcLDiKwEaeWaGp8v_YS3j4iGqkcAytf7z_-toD1O3ZHtIUlbe6H64IAVPKadN1Y1SD49Ouk1fk8xDFr7HQ4RuDTLfZnLGzC4vvzysCmJEX837Wjf2f9WdirEaKxoSlDDJKilt--20Ota-5CTimD8u0SttC6CD1Glj8bbAS8ddCAfVirDJty7FW3eyALvAHifKqzRa1kBDPHb305q91oSWYdzBKIlTinN9BAXDc3ZccVkWM6Y3VgUzh2iQwM0lKadts7OMwqhLDk7rukAXHRUpKxy-85rUf-a0oz41s69PXdQteoh559vEb0uyrq0kOnI1RnuJ7MaEGDC25Kfezumo0snwYRmQhXMPMeKkxBKxs9ZydKxxcp1qtLwFyHA6MhZuXRpZM9Qse9mqovNdHHOhAQIZu3J7HJusuVdg3SJhZkTH__gXpCc2hBeOpR0rPc6qZm7z2nU5pJQ2XgzH2TUm6psA",
"ims_user_id": 8873576,
"token_type": "Bearer",
"expires_in": 3600,
"expiration": 1614259586,
"refresh_token_expiration": 1616847976,
"scope": "ibm openid containers-kubernetes"
}
In addition, the following approach works but the token is obtained through the OpenShift web console, and thus cannot be obtained programmatically(at least I don't see how),
"Authorization: Bearer sha256~6V_OvZ5OoV8vnHF33Es5qsloAY-iXkLQ8dfl_Nsyn94"
Thanks!
You can not and should not send the ID-Token to get access to APIs, its only meant to be used by the client who did the initial authentication. It also typically have a very short lifetime (like 5 minutes in some implementation).
The only purpose of the ID-token is basically o create the local user session.
On the page you refer to it says at the end:
ID token: Every IAM ID token that is issued via the CLI expires after
one hour. When the ID token expires, the refresh token is sent to the
token provider to refresh the ID token. Your authentication is
refreshed, and you can continue to run commands against your cluster.
It sounds like they mean the access token. In openID connect you don't renew your ID-token (what I am aware of)
Have been busy in the past few days, I will share how I solved this problem here. In fact it didn't address the original issue, but is another way to achieve the goal.
So it turned out that there was another doc regarding how the access token can be obtained(Yes, as mentioned by #Tore Nestenius it should be an access token instead of an id token). The token described here is actually the same as what one would get through the Openshift web console. And basically it has nothing to do with the previous link I shared in the question.

Uber GET requests 403

I am trying
curl -X GET -H "Authorization: Bearer <TOKEN>" "https://api.uber.com/v1.2/requests/<REQUEST_ID>"
and response is 403
{"message":"Forbidden","code":"forbidden"}
But the https://developer.uber.com/docs/riders/guides/scopes says that
The good news is you currently have access to these scopes when authorizing your own account or those of the developer accounts you list in your application dashboard (Limited Access). This allows you to start building an app immediately.
I've got token via OAuth using my own account
I've set param "scope=request" to https://login.uber.com/oauth/v2/authorize
And I've set "scope=request" when did https://login.uber.com/oauth/v2/token
Also I've trying to do request to https://sandbox-api.uber.com, it responds
{ "message": "cannot find trip", "code": "not_found" }
But I think it's ok, because sandbox doesn't contain my own account data, right?
Where is my fault could be?