Somehow, I have the feeling that I’m missing something here in the authentication process. I’m using a Photon to remote-control some hardware, and now I’m trying to build a proof-of-concept control application. I don’t have any plans to extend this beyond the POC, but I’d like to get the concept right. The control application is based on a commercial/proprietary database-backed application server/programming environment; I can’t use any of the libraries, so I’m down to implementing the REST calls myself.
My initial question was: Do I keep the user and password to myself, generate an access token and enter that into the configuration of the application, or do I place my (or another?) user/password in the configuration of the application server and have my control application generate its own access token? Though reading other answers in the forum, I got the impression that the application needs to generate their own token since tokens expire periodically - right?
Now I don’t really like to share my fully-privileged development account credentials. I understand there’s a way to create an OAuth Client, that will give me a “secret” that I can use in conjunction with the app name - but where? Does it replace my username / password, or does it replace the -u particle:particle part of the token acquisition? That wouldn’t make any sense, since the default particle:particle appears to be hard-coded.
If there are some additional resources to read, please let me know - I’ll gladly accept RTFM requests outside of the Particle docs (that do a good job explaining the basic call structure, but IMHO don’t really explain how everything fits together in the big picture).
Fair enough. You can now actually set the expiration date of tokens to accommodate your needs. The ones from the Web IDE will be definitely, while those from ParticleJS seem to have a limited lifespan. @jeff and/or @dave should be able to give you some more concise answers, so perhaps we’d best wait for them to wake up
Yes you can set a custom lifetime for your access_tokens when creating them. We create a non-expiring token for you in the IDE because a lot of people used that one by default and were surprised by the previous default expiration window.
thanks - so much for the access tokens. I don’t mind generating them in my application, it’s no big deal really. Now what about these OAuth Clients - do I need them for anything or are they just something that might be handy in the future but isn’t completed yet? The documentation isn’t very clear about that, I’m afraid…
OAuth Clients let you create and distribute software that lets your users log into their Particle accounts via your app. This can be especially useful if you have an organizational product, and you want your own branded app / customer accounts, etc. This is available now, and you can generate your own oauth clients. We’ve been extremely open, and haven’t strictly required official oauth client credentials, but it’s something that might become required (still easy to create a set of credentials), and it’s generally a good practice to use an oauth client setup / creds when building apps.
Thank you, that link was very helpful to get the big picture. Now, as far as I understood this, to do this “the proper way”, I need to create customers, which means I need to create at least one organization, which in turn means I need to pay an additional $49-$55 per month - right?
