6 Replies Latest reply on Jul 14, 2014 3:33 PM by mark.weitzel

    No way to store user data securely from an app

    ztenerowicz

      I need to save an access token to external service for every app user.

      I found this doc: Extended Properties that even declares it's useful for "Storing 3rd party credentials (for e.g. OAuth token) of the jive user"

       

      The problem is:

      • Extended Properties of a Person are accessible to all other users using the same application, therefore my token can be read by any other app user with help of developer tools in the browser
      • Private Properties of a Person are accessible to all other apps, therefore any other app I use can read the token (I tested)


      I was unable to find any storage available to Jive apps that would maintain a contract to only be accessible when app&user are matching.

        • Re: No way to store user data securely from an app

          zbigniew tenerowicz,

          If the extended properties won't work b/c of the readability from the browser, then we don't really have a good answer. I was talking through this with a few of the engineers and we don't have anything like this OOTB. We kicked around using a private doc that gets created and using its extended properties. This would be readable only by the user. However, the user could delete the document, which would remove the keys, & the security token would not be secure in Jive's DB.

           

          We talked through Jive Connects (if you are using an app), but these are only static keys. The closest we came up with was (and this is a bit wonky) using basic auth. The idea here is that you setup a basic auth scheme. You have a mechanism to provide the generated key to the user. They would need to cut/paste that key into the prompted password box and give you the user name. You'd then get this in base64 encoded header field. This would be stored in the Jive's credential vault and placed on every request made from the app. (If you are using ESF, it's not included in those requests.)

           

          Are you using an app, the ESF, or both? Another option we're trying to figure out is if there's an easy way that you might be able to have a "mapping proxy" in place that captures the unique jive instance/user combination and substitutes the specific key you need.

           

          Thoughts???

            • Re: No way to store user data securely from an app
              ztenerowicz

              I am building an app packaged as an add-on (stating this in case it affects the matter)

              The app leverages embedded experiences.

              (We can leave ESF out of it, as the app is going to be distributed both with and without the ESP add-on)

               

              The app goes through a normal oAuth flow, the user logs in and the app is given a token that gives it the access to public API as the user. The token needs to be added to the queries as an authorization header. Currently we don't have other options.

              Once the user logs-in I have the token string in a variable in my app's code. I need to get it back there the next time the user opens the mentions view.

               

              If the token is accessible by another user or any app except ours, it is equivalent to the user publishing his login and password.

               

              Is this really the first time someone decided to store an oAuth token for the app user? How do other apps handle oAuth?

               

              1. The idea with the document might be acceptable, but I'm not sure what you mean by "the security token would not be secure in Jive's DB". Is it accessible to any third parties then, or just Your engineers? Because, honestly, if they wanted to get the oauth token I use in a Jive app, there's no stopping them anyway, so this is bad only assuming Jive leaks data.

               

              2. We could explore Jive Connects more if it is possible to configure the connection on a "per user" basis, so that every user would have a separate secure communication with some server of ours and nobody else could perform the same request. This sounds like a reasonable fallback for our situation. But is the Jive Connects setup limited to my app only or is another app able to also use the same connection if ran by the same user? I don't follow the part where you say the user would have to copy-paste something.

              Implementing this will significantly delay our app.

               

              3. "jive instance/user combination" is something that would be as available to other apps as the privareProperties storage, right?

               

              4. Is there a way to store the data privately for the length of the user session only? It could be enough.

               

              5. And last but not least: what would be the timeline for adding "privateExtendedProps" that would be private per user+app pair in Jive? It can't break backward compatibility and we could just define a version requirement in our app.

                • Re: No way to store user data securely from an app
                  1. The idea with the document might be acceptable, but I'm not sure what you mean by "the security token would not be secure in Jive's DB". Is it accessible to any third parties then, or just Your engineers? Because, honestly, if they wanted to get the oauth token I use in a Jive app, there's no stopping them anyway, so this is bad only assuming Jive leaks data.

                  What I mean is that this token will not be encrypted in any way. It would not be accessible to third parties because, even though they could get the document, they can't read the extended properties for your app.

                   

                  2. We could explore Jive Connects more if it is possible to configure the connection on a "per user" basis, so that every user would have a separate secure communication with some server of ours and nobody else could perform the same request. This sounds like a reasonable fallback for our situation. But is the Jive Connects setup limited to my app only or is another app able to also use the same connection if ran by the same user? I don't follow the part where you say the user would have to copy-paste something.

                  Implementing this will significantly delay our app.

                  The connection would be per user, but it would look like basic auth. This value does get stored in Jive and not on the client. However, each user would have to be given their unique key, so at least once, this would be passed down to the browser. And the user experience may not be all that great.

                   

                  3. "jive instance/user combination" is something that would be as available to other apps as the privareProperties storage, right?

                  The "mapping proxy" idea is simply a way to keep a table of user tokens on your end and intercept the incoming request, substitute the right token, and then forward the request on. There is a way to verify that the request comes from a valid jive instance so you can avoid the man in the middle attacks.

                   

                  4. Is there a way to store the data privately for the length of the user session only? It could be enough.

                  Not sure if the app itself can create a cookie of some kind. That might be worth trying out. You could have a short lived cooked and a revalidation process that is all under the covers. This actually leads to another idea....

                  What if each request token was a nonce? This might be a bit chatty, but you could...

                  a) request the nonce (security token)

                  b) add that to the security header

                  c) make the request

                  A variant of this might work if the access token is short lived, e.g. 20 seconds.

                   

                  5. And last but not least: what would be the timeline for adding "privateExtendedProps" that would be private per user+app pair in Jive? It can't break backward compatibility and we could just define a version requirement in our app.

                  We've hit this rough pattern a few times. We'd have to map out exactly what the use case is. Ric Goell is the PM and we can open the feature request and see where it might fall on the roadmap. Given what's on the plate now, I can tell you it's not likely any time soon.

              • Re: No way to store user data securely from an app

                zbigniew tenerowicz,

                Would you post a quick example of your test for private properties? We were talking about this again, and Edward Venaglia mentioned that private properties should be visible only to the user that created them within that app. Private properties can be attached to the v3 Person object only.

                1 person found this helpful