Customer's Scoped Access Tokens return "organization not found" on all calls

Cloud
1

Dear All, I am getting back again with an issue I have been trying to solve for the last couple of days.

The situation is as follows: I am building a web-app (two-legged auth) and have created a product, and linked devices to it. There are team members (with email and password), as well as customers (with email and NO password) registered.

I have been testing all my function and variable calls, as well as retrieving information on devices and unclaiming devices with access_tokens from my team members. This does work perfectly fine. As a next step I was testing this with my customers (who are only registered with an email in the particle.io backend (as said above)). When using their scoped customer’s access_token (which I renew at every login), the call give’s me a
{ "ok": false, "error": "Organization not found for user's role." }

Do you have any Idea why this might be the case?

The renewal of the access token is done via:

curl -X POST -H "Content-Type: application/x-www-form-urlencoded" -H "Authorization: Basic %MYHASHEDUSERNAMEANDSECRET%" -H "Cache-Control: no-cache" -d 'grant_type=client_credentials&scope=customer=mailOfCustomer@host.com&client_id=%MYCLIENTID%&client_secret=%MYCLIENTSECRET%' "https://api.particle.io/oauth/token"

And it returns the desired access_ and refresh_tokens:
{ "token_type": "bearer", "access_token": "%THEACCESSTOKEN%", "expires_in": 7776000, "refresh_token": "%THEREFRESHTOKEN%", "scope": "customer=mailOfCustomer@host.com" }

Thus I did expect them to be working just as the ordinary access_tokens from my team members. What am I doing wrong?

I would like to avoid calling my backend from the app and then calling the particle.io backend from mine (as this is just unnecessary calls and latency and ist just not neat… :wink: ). Including my “team-member token” in the javascript (which I can do now for testing) is obviously not a solution for the production phase.

2

@jeiden

3

Hey @partTee,

Thanks for the question, sorry you’re running into issues. One thing I notice that in your API call to create the token for the customer, you are passing grant_type=client_credentials. This instructs the Particle API to use an OAuth client credentials to authenticate the request. However, you are passing an access token in the Authorization header.

Can you try creating an OAuth client scoped to your product (can be done either in the console UI or through this endpoint) and instead of passing an access token from a team member, passing the OAuth client ID and secret like this?

$ curl -u my-org-client-1234:long-secret -d grant_type=client_credentials -d scope=customer=jane@example.com https://api.particle.io/oauth/token

For more info, please check out the docs: https://docs.particle.io/reference/api/#generate-a-customer-scoped-access-token

4

Hey @jeiden!
Thanks for helping me with this. Actually I am using an OAuth client (two legged, full-access) in the header for authorization. (Where I wrote %MYHASHEDUSERNAMEANDSECRET%)

I have tried the call you posted (which is basically the same I am using, just without the (unnecessary client_idand client_secret in the message body). It also generates an access_token and refresh_token nicely. When using this token to in e.g. the following call:

`curl -X GET -H “Content-Type: application/x-www-form-urlencoded” -H “Cache-Control: no-cache” “https://api.particle.io/v1/products/%PRODUCT_SLUG%/devices/�VICE_ID%/?access_token=�CESS_TOKEN%”’

it returns the “Organization not found for user’s role.” message…

If it should help I could provide you my product slug via private message?

5

Hey @jeiden: I am facing the exact same issue as @partTee. Was this issue ever resolved? If so, can you point me to the resolution?

1 Like
6

Hey @ruku! As I didn’t find a solution for the problem outlined above I am now routing all requests from my app through my backend. In the backend I keep keep the credentials of a team member account. So it appears to the particle backend like requests from a team member and not from the individual user.
It’s kind of messy but it works for now and allows to test the system and move on with implementing further functions. Additionally I ave the advantage, that I can actually track every move the user makes.
(sry for using a different account - seems like I got mixed up with my passwords for the forum…)

7

Thanks, @Duesentrieb! Based on some additional testing, I found that any of the API calls that include a productIdOrSlug in the URL will require an access token scoped to the product (i.e., an access token created with the clientId and secret, but without any scope specified). If you want to use a customer-scoped access token, you can call the devices endpoint without productIdOrSlug, i.e., /v1/devices. It will return the devices that belong to the user represented by the access_token specified. @jeiden: Can you confirm this?

8

@ruku that is correct. I will make one small addition to what you said:

I found that any of the API calls that include a productIdOrSlug in the URL will require an access token scoped to the product (i.e., an access token created with the clientId and secret, but without any scope specified)

In addition to "scopeless" access tokens generated by a client ID and secret, any access token generated by a Particle user belonging to the product team will also be accepted when authenticating with product-specific endpoints. This is how the Console calls API endpoints scoped to a product when you are logged in. If your Particle account is part of the product team, you can grab an access token to use by running particle token list in the CLI.

Customers should use the non product-scoped endpoints when interacting with their devices, like /v1/devices or /v1/devices/:deviceId as you mentioned.