2 leg auth, Create customer Failing kind of

[enderki]

Hey, There I’ve Been try to get the 2 leg auth to work. mostly just create a customer

also i’ve already review the post similar to this but, find i’m still having problems.

I’ve area gone through the process of making a client. Currently what i’m submitting is the following.

curl -u "b*****alpha-v02-4****:9a*********5" -d email=testCustomer012@testEmail.com -d no_password=true https://api.particle.io/v1/orgs/fakeorgslug/customers

I’ve also try doing versions where I’ve pass the my access token -H “Authorization: bearer 1234”

Based on the format from the guide docs. I don’t use ‘-X POST’ it just returns me error if i do.

curl -X POST -u "client-id-goes-here:client-secret-goes-here" -d email=abu@agrabahmonkeys.com \
-d no_password=true https://api.particle.io/v1/orgs/particle/customers

I’m getting errors. Scope errors, even though the current client i’m pointing to doesn’t contain any required scopes. this happens with versions that have scopes and none.

{
  "ok": false,
  "code": 400,
  "error": {
    "name": "OAuth2Error",
    "message": "Requested customer scope doesn't exist",
    "headers": {
      "Cache-Control": "no-store",
      "Pragma": "no-cache"
    },
    "code": 400,
    "error": "invalid_scope",
    "error_description": "Requested customer scope doesn't exist"
  }

But what’s really making me scratch me head is this error after if have submitted the the block again. What I get from the error from before I asume that it didn’t create the customer but.

{
  "ok": false,
  "code": 400,
  "error": "customer_exists"
}

I check the customers tab in dashboard and also used the GET version of it and I get an empty window/array.

GET /v1/orgs/:orgSlug/products/:productSlug/customers

Anyone noticing something I’m missing or not doing right? btw I’m using a Web type client not sure if that matter in this case.

Thank you for any advice in advance.

[indraastra]

Adding a +1 to say that I also noticed this issue with clients created without any scope, albeit with a different error code (503):

Example Web Setup App (Simple Authentication)

@G65434_2 - To tease apart OAuth setup issues from request construction issues, have you tried creating customers using the curl request templates from the docs? I assume you’re using simple auth, which means you probably created a client using a request like this: $ curl -X POST -H "Authorization: Bearer [access_token]" -d name=[name] -d type=installed -d organization=[org-slug] -d scope=create_customer https://api.particle.io/v1/clients I created two clients, one with -d scope=create_custome…

At that time, the client created WITH the "create_customer" scope was successfully able to create customers, so I don't know if there was a regression or what. Either way, customers seem to be getting created somewhere despite the error.

[ShotLine]

I am having this exact same problem except I do not have an organization I have only a product (is that a recent update or something?). I came across this while following your guide and was in the ‘Create a customer’ section: https://docs.particle.io/guide/how-to-build-a-product/authentication/#3-create-a-customer-1

The curl command I am using is:
curl -X POST -u “CLIENT_ID:xxxxxSECRET_HERExxxxxxxxx” -d email=testerMail15@fakemail.com -d no_password=true https://api.particle.io/v1/products/[productID]/customers

The first time I try I get the same response as enderki:
{
“ok”: false,
“code”: 400,
“error”: {
“name”: “OAuth2Error”,
“message”: “Requested customer scope doesn’t exist”,
“headers”: {
“Cache-Control”: “no-store”,
“Pragma”: “no-cache”
},
“code”: 400,
“error”: “invalid_scope”,
“error_description”: “Requested customer scope doesn’t exist”
}
}

If I run it again I get the same thing as well:
{
“ok”: false,
“code”: 400,
“error”: “customer_exists”
}

The customer, which apparently exists, does not show up in my dashboard. I do think I remember reading somewhere that the dashboard only shows customers that have devices, but i cant find that so am not sure if its true. Also the fact that I am getting the error 400 and not the access_token is problematic…

Thanks for the help!

[ShotLine]

Hmmm, so it seems to have mostly resolved itself. Now the same call returns the appropriate response with a customer’s access token and whatnot. That said, the customers still dont show up in my dashboard, are they supposed to or do they only show up once they have a device associated with them?

[jeiden]

@ShotLine

ll returns the appropriate response with a customer's access token and whatnot. That said, the customers still dont show up in my dashboard, are they supposed to or do they only show up once they have a device associated with them?

Glad to hear you got it working! Your suspicions are correct, the customer won't appear on your list until they claim a device that is part of your product!

[LukeUSMC]

@jeiden

working

Good to know on that one! Do you have any recommendations on patterns or known good product owner authentication systems? I was looking at SuperLogin + CouchDB + PouchDB (Pouch for user setting sync) and some Particle specific extensions to create the shadow users etc. Would be awesome if any details existed on examples of creator systems using two-legged auth. BTW, would love to see specifics/patterns on the common workflows for people that are writing apps. I am making good progress on an Ionic based app and about to take on the device setup phase of things but I am hopeful. Happy to hand over any code related to particle so that others have this route to mobile/hybrid apps as well.

GitHub - colinskow/superlogin: Powerful authentication for APIs and single...

[jeiden]

Hey Luke,

Currently, we just have the high-level flow of two-legged auth documented in full here: https://docs.particle.io/guide/how-to-build-a-product/authentication/#two-legged-authentication

In the future, we’re planning to build open-source example/“starter” apps to help people get going quicker. Stay tuned for that.

• Jeff

[willd]

Hmmm, so it seems to have mostly resolved itself. Now the same call returns the appropriate response with a customer's access token and whatnot.

I'm running into the opposite of this issue. Earlier today, I was able to create test customers and get the expected response with tokens. Now, after a couple hour break, I'm receiving the ""message": "Requested customer scope doesn't exist", response. I've created quite a few customers today trying to diagnose this and quite a few sorting out a parsing issue (my end) earlier. Could I have hit some kind of limit?

Thanks for any advise,
Will

[appocalypse]

I have the same problem :-/

[rpk788]

I’m seeing the same problem here and I guess I created a duplicates issue here: Error creating “shadow” customer with two-legged authentication

I guess I will try creating an access token for this user and claiming a device to see if the customer shows up in the dashboard after that. I will probably try passing the scope=create_customer parameter as well to see if that fixes the original issue.

Is it confirmed that the scope value is required? Is there a way to make the make it a bit clearer or the behavior more clear? Seems weird to get a BadRequest but the customer is still created somehow.

[sdevo619]

Hey Guys,
I hope someone in this thread may be able to help shed some light on what is happening. I have a mobile app with simple auth and can login a client with no issues, but as soon as try to login a CUSTOMER, I am running into errors constantly.

There are some noticeable differences between a client and a customer in the token creation process from the a standpoint of the http body, and this where I am afraid I running into issues. I have tried multiple different body configs using all the examples in the current docs, and some from the forums too, but if I can’t get past the errors listed below, with any customer account i try to create.

As I said, I can generate the access token and login with no problems for a CLIENT, BUT when I attempt the same for a CUSTOMER, I running into error. The customer may or may not actually get created at this point, but as I don’t receive token in return and only errors, my suspicion is that they don’t.

What I am asking for, is for a current, meaning as of July 4th 2020, or a confirmed example from within the last month at the oldest, of a request, that will generate a user account and token and return the token. The particle docs on this, I can tell, are either not up to date, or leave out some rather important information.

WORKS FINE for a CLIENT - https://docs.particle.io/reference/device-cloud/api/#generate-an-access-token

Customer First way:
https://docs.particle.io/reference/device-cloud/api/#create-a-customer---client-credentials

Error: [“error”: inval:id_scope, “error_description”: Permission denied]

URL: “(mainURL)/v1/products/(. productID. )/customers”

Customer Second Way:
https://docs.particle.io/reference/device-cloud/api/#generate-a-customer-scoped-access-token

Error: [“error”: invalid_client, “error_description”: The grant type is unauthorised for this client_id]

URL: mainURL + “/oauth/token”

The goal here being, to be able to create a new customer from inside the mobile app. Any help you can provide here would be very much appreciated. Thank you!!!

[rickkas7]

We do not recommend creating a two-legged customer from a mobile app directly. The reason is that in order to use the create customer API, you need to have a full access product access token. This means that you either need to embed a full access non-expiring product token or the secret key for an oAuth token in the mobile app, neither of which is secure.

In order to create two-legged customer you’re going to want a server-based back end to handle customer management since this is not handled by the Particle cloud for two-legged auth. It’s from this back-end that you create the customer, since the back-end can safely keep a full-access product token. You will need to create a product bearer token to do this in your back-end.

For two-legged auth, you create the customer on the back-end and pass the customer token back to the mobile app through an external channel and store with the mobile app. If this token is compromised, it only affects access to the account that is associate with that mobile device, which is reasonable.