@blardo 100% agree, would love to see us get this added.
Ideally Skuid Platform would be able to act as a true OAuth 2.0 provider, with the ability for each site to register OAuth clients, which could be revoked/managed individually, and with support for Refresh Tokens. Then, Skuid CLI could perform a proper OAuth 2.0 login process, where we could open up a browser window to have the user authorize the OAuth client, and then get back a refresh token, which, for local development especially, the Skuid CLI could store locally in a hidden folder, along with access token. Then whenever the Skuid CLI was used, it could attempt to use it's access token, and if it is expired, it could transparently use the refresh token to obtain a new access token --- thereby eliminating the need for the user to ever store their username/password locally. I've seen this pattern performed excellently with a few different CLI tools (sfdx, dmc) and it's very nice.
For CI environments, we could also support the "Resource Owner Password Credentials" or "Client Credentials" grant types so that in CI, Client Id / Client Secret / Username / Password could be provided as ENV variables and we could perform a headless grant.
It would be therapeutic for me to implement this on Skuid Platform sometime in the next 2 months. We'll see how much time I have for "therapy" :)
@blardo 100% agree, would love to see us get this added.
Ideally Skuid Platform would be able to act as a true OAuth 2.0 provider, with the ability for each site to register OAuth clients, which could be revoked/managed individually, and with support for Refresh Tokens. Then, Skuid CLI could perform a proper OAuth 2.0 login process, where we could open up a browser window to have the user authorize the OAuth client, and then get back a refresh token, which, for local development especially, the Skuid CLI could store locally in a hidden folder, along with access token. Then whenever the Skuid CLI was used, it could attempt to use it's access token, and if it is expired, it could transparently use the refresh token to obtain a new access token --- thereby eliminating the need for the user to ever store their username/password locally. I've seen this pattern performed excellently with a few different CLI tools (
sfdx,dmc) and it's very nice.For CI environments, we could also support the "Resource Owner Password Credentials" or "Client Credentials" grant types so that in CI, Client Id / Client Secret / Username / Password could be provided as ENV variables and we could perform a headless grant.
It would be therapeutic for me to implement this on Skuid Platform sometime in the next 2 months. We'll see how much time I have for "therapy" :)