Authentication Key

flocsy🤠 said:

This sounds like a X Y problem (https://en.m.wikipedia.org/wiki/XY_problem)

You got hit with the forum linkification bug :/ (don't forget to press space backspace after a link and before punctuation)

flocsy🤠 said:

And why don't you use System settings.uniqueIdentifier?

flocsy🤠 said:

Or the user's email address?

Or oauth?

DaveBrillhart said:

That string is available to the server once the activity is uploaded.

If I'm understanding correctly, the server both handles web requests from the CIQ app, and receives FIT files from Garmin Connect, and this is a way to correlate the user who is making web requests with the user who uploaded the FIT file(s) associated with said requests, without requiring the user to do anything (like enter values in settings or use oAuth). The server generates a random ID and the app stores said ID in the FIT file.

Aside from the fact that this isn't really the best "authentication" method, using System.settings.uniqueIdentifier or OAuth doesn't get around the issue that the id will be shown in Connect, and using the user's email address will require them to enter their address in settings (which OP said he doesn't want to do). I agree that using DeviceSettings.uniqueIdentifier would be a better way to track devices uniquely. (uniqueIdentifier is unique for the given combo of device and app.)

Having said that, if you're going to track your users this way, it may as well be transparent, and part of that transparency would be having the value that you save to the FIT file be shown in the Connect activity information, no matter what that value is.

So let's clarify what this means:

DaveBrillhart said:

A user runs a CIQ field which stores their String (saved in persistent storage) as a FIT SESSION string. That string is available to the server once the activity is uploaded. A one time "registration" upload. Until they use another device, or hard reset it

If this means that the app checks if the random string is in the storage, and if not then generates a random string and then records a 1 second session with this data so it's uploaded to Connect and from there to the app server, then I don't see why you can'y use uniqIdentifier+oauth instead: you don't add the uniqIdentifier it to the fit file. But you redirect the user to the oauth login page, including the uniqIdentifier in the request url. Then you save in the app storage the oauth token, and later you use this token for all web requests. It adds complexity, but if I was using this datafield, then I would prefer this way than wasting the precious datafield session data to the random string. I'd rather do the login once and be able to add another datafield that also saves data to the fit.

Like I said above, I think the point is that the server wants to be able to correlate FIT files (presumably synced from Garmin Connect) with web requests. I presume that the server has been given permission to sync FIT files from the accounts of participating users, and that the server knows which user has uploaded a given FIT file.

I don't see a way to do this except by storing some sort of ID in the FIT file, or by telling the app the user's Connect email address or account ID.

I just explained above how to do it.

1. user probably already went to the website and connected to garmin connect. If this (opening the website) was triggered from the device then it could already have saved the uniqIdentifier.

2. if it wasn't triggered from the device, then another step is required, when the device triggers the opening of the website, including the uniqIdentifier. The user will need to log in to the website (actually it might already be opened in the default browser on the user's phone, where they might be already logged in and then it's just opening the page, the server saves the uniqIdentifier to the DB under the user's profile, and then closes the page)

3. no extra data needed in fit file (since the connection between the website and Garmin Connect already identifies the user, in the web requests the uniqIdentifier can be sent.

4. when user changed garmin device step 2 needs to be done again

But maybe instead of guessing let's wait what Dave will say :) 

Sorry you’re right, my bad.

It makes a lot more sense for the device to send a unique identifier with all web requests and for the server to save it server-side, as opposed to the other way around (the server generating some ID and requiring it to be saved in every FIT file).

The only thing is that it would require the user to log in (e.g. using oauth) to identify themselves, as you said. Simply sending DeviceSettings.uniqueIdentifier wouldn’t be enough, as the server needs a way to associate that uniqueIdentifier with an actual user that uploads FIT files.

So it still doesn’t fit the apparent requirement of not asking the user to do anything with regards to “authentication”. (I assume that asking the user to log in via OAuth is roughly as onerous as asking them to set username and password in app settings.)

I imagine that the server could try to correlate uploaded FIT files with certain values that could be sent by the app, such as activity start time (since the start time will also be recorded in the FIT file). But of course that falls apart if two users start their activities at exactly the same time. 

The server could also try to correlate FIT files with additional information from the user profile (birthday, height, weight), or from the starting GPS location (assuming the activity is outdoors), but there’ll never be a perfect method to avoid false matches.

From the user's perspective IMHO it's either the same or better to ask them to log in on the website instead of saving a password in the device storage, because a) it's more secure, b) I think (haven't tested) the website would be opened in the user's default browser on the phone and they might be already logged in there, and if not, then they might be able to log in with 1 click (i.e: password manager) rather than typing the password in the device (or Connect IQ app)

Sure I agree. I also think that what’s described in the OP isn’t really a good form of authentication.

Obviously oAuth is far more secure and reliable.

I’m just going by the context of the OP where they apparently want the entire process to be invisible to the user (including hiding the authentication process altogether). I don’t claim that’s necessarily a good strategy (either for the dev or the user), but that’s what they want.

I mean it seems that the goal is to "magically” authenticate (track) users without them being aware of the process. Obviously they have to know at some level, since they are presumably using the service where the 3rd party server reads their FIT files. But it doesn’t seem to be ideal from a privacy and security pov.

Usually when 3rd parties track us without our knowledge, it’s seen as predatory (e.g. 3rd party advertising / social media trackers).

I could think of a way to do it without user doing anything:

1. create a random string, do a web request and pass the uniqIdentifier + the random string => webserver saves both

2. save the random string to a fit file

3. The next time the user will sync, the fit file will be sent to the server, where it'll notice the user is new, and identifies the "connection" fit file, and then connects the user's Garmin Connect ID with the uniqIdentifier. 

4. at this point the random string is not needed any more, and can be removed from both the server and the device, as well as the "connection" fit file (aka the activity) from Garmin Connect

That’s already what OP said except for step 4.

Their concern is that the “random string” will be shown in Connect activity info, and they don’t want that, because they want the whole process to be invisible. I would claim that making the whole process invisible isn’t necessarily good for the user but that’s what they want.