Password and secret end up flows.json

[gorenje]

Hi There!

First off, great work and nice job making OAuth2 so simple!

But ... when I select password authentication, the password and secret end up as cleartext in the flows.json file, making the flows.json non-distributable nor checkin-able.

I did something similar but made the secret field an environment variable by using typedInput:

in the .html:

<!-- snippet -->
  <div class="form-row">
    <label for="node-input-apiToken">
      <i class="fa fa-tag"></i>
      API Token
    </label>
    <input type="text" id="node-input-apiToken">
    <input type="hidden" id="node-input-apiTokenType">
  </div>
<!-- snippet -->

<!-- snippet -->
 oneditprepare: function() {
      $("#node-input-apiToken").typedInput({
        types:["env", "msg", "flow","global", "cred"],
        typeField: "#node-input-apiTokenType"
      });
      ...
  }
<!-- snippet -->

in the .js:

node.on('input', function(....) {
      RED.util.evaluateNodeProperty(cfg.apiToken, cfg.apiTokenType, node, msg, (err, result) => {
        if ( err ) {
          node.error( "Failed to get API token" );
          node.status({fill:"red",shape:"dot",text:"Failed to get API token"});
        } else {
          var apiToken = result;
          // have token, will travel
   ....

I don't know how that could work with a config node but I guess that would be best solution.

just a suggestion :)

[caputomarcos]

Dear @gorenje.

Thank you for your valuable feedback and suggestion.

I genuinely appreciate your input!

I'm pleased to know that you found OAuth2 easy to use with this package. I completely understand and acknowledge your concerns regarding storing the password and secret in plaintext within the flows.json file.

Moreover I am grateful that you shared an alternative approach involving the use of typedInput. Your suggestion of making the secret field an environment variable is truly intriguing. As it offers a significant enhancement to security measures. It is definitely worth considering implementation of something similar or adapting your suggestion to work with a config node. Rest assured. Your input holds immense value! Thank you once again for your contribution!

Warm regards,

Caputo

[tglynx]

Dear @gorenje, dear @caputomarcos,

i hit the same issue and fixed this already in my forked repo in the issue-credentials branch. I am going to create a pull request if appropriate and after some more testing. Feel free to test that version already (please note that already entered password and client-secret will get deleted and have to be entered again).

https://github.com/tglynx/node-red-contrib-oauth2/tree/issue-credentials

For your reference, i implemented it as suggested here: https://nodered.org/docs/creating-nodes/credentials

I don't know how that could work with a config node but I guess that would be best solution.

I am also working on a version with a config node in a separate branch but that is just a prototype yet.

Regards, Michael

[tglynx]

Hi,

just a short update on this issue and to share some ideas! I have a working prototype with both solutions implemented as discussed above.

Remove credentials from flows.json and encrypt Before (Password and Client Secret are visible in the 'Info' Sidebar of the node and are stored in flows.json in cleartext:

After the patch (Password and Client Secret are no longer visible in the 'Info' Sidebar of the node and are no longer stored in flows.json):

The credentials are now stored in encrypted form in flows_cred.json (node-red standard / encrypted with the credentialSecret from settings.js).

This part is already working fine. However, as already said, Password and Client Secret will be lost if using the new version and need to be reentered. So make sure you have them backed up before changing the node.

Store credentials in reusable config node In addition to this, and to learn how its done - i implemented a config node to store the credentials as a new 'grant type':

In the config node you can still choose from the 3 remaining 'grant types' that make sense there (Client credentials, Password, Authorization Code):

... the config node part is work in progress ... https://github.com/tglynx/node-red-contrib-oauth2/tree/hapec

After some thinking i did put most of the fields in the config node (as seen in the screenshot above). Also i think scope and resource can be considered part of the credentials (so also stored in the config node).

I need to dig a little deeper into the authorization code grant type. I have not fully understood how this works and i do not feel confident to implement that part correctly in the config node yet. Also - not visible in the screenshot - when selecting the other grant types in the oauth2 node itself all functionality remains working as before, so one could choose to still use a locally configured password authentication without using a config node as an example.

Regards, Michael