This seems to be a reoccurring problem for me as I seem to gravitate around mobile applications the last few years. I want to authenticate and authorize mobile users in addition to web users. I need to make this seamless enough so that users can ease into having a web account without causing interruption to their data. I want the solution to be architectural in topic, not specific to any language/framework.
Requirements/Assumptions
Mobile users must be able to use the native application without a login, including for contributing content (marking favorites, uploading photos, etc).
Mobile user should be securely and uniquely authenticating to the web service even without specifying account credentials.
Mobile user may have multiple devices, which will be unaware of each other.
Mobile user should be able to Register/Login, which should roll in any content into the account's ownership. This "synchronization" should occur with each account that is subsequently logged in.
It should not matter whether an account was created on mobile or web.
Architectures Considered
NO SHIRT, NO SHOES, NO LOGIN = NO CONTRIBUTION. Require login to contribute content of any kind. This prevents the need to "synchronize" device accounts with a master account. Simply require a single username/password + tokens in order for devices to login. Server objects: User, Role
Multi-device self-authentication. Server negotiates with device and hands it credentials which the device stores. Each device self-authenticates and is associated with an anonymous account until Register/Login occurs. If Register occurs, anonymous account is converted into known account. If Login occurs, content from anonymous account is moved over to known account and then thrown away. Devices that lose the self-authentication details will get new authentication details, and the previous anonymous account is abandoned (and then hopefully later thrown away) and not restorable since it was never converted into a known account. Server objects: User, Role, Device
What do you think is a good solution? One of these, or something else?
I would like to propose an idea similar to 2.
Generate an UUID per mobile device. It will serve to identify the device on later occurences when the user generates content and the content is sent to the server.
If, at any time later, the user wants to create an web account, he may register either on the web or on the device. If the user already owns a web account, he may opt to provide the existing credentials on his mobile device once (or devices) and the device is linked to his web account on the server-side.
On the server side, I would allow two different types of entities serving as identities: Web Users which are authenticated by credentials (OpenID comes to my mind as an addition) and devices which are authenticated by their GUID without user interference. Naturally, a web user entity may own several device entities. A device entity is linked to an account when the user opts to link his device to an existing account. Content is generally associated with an identity.
The linkage between user and device is kept and could also be used to display the origination of content.
You would not need to create/drop/convert accounts with generated credentials for mobile users. You would also not need to store the credentials on the mobile device.
There are still some security considerations left open, depending on the criticality of the context of your application. Without any security measures, an attacker would find it easy to abuse the UUID.
I think this is being looked at from the wrong direction. Define an identity on the server as being defined by an arbitrary value. Probably just a DB sequence. Associate any demographic information (name, email...) and usage history with this identity.
Separately, define an authentication entity on the server. This could be a user/password. It could be a device GUID/UUID. It could be a federated ID like OpenID. A given identity can have (and often will in your use-case) multiple associated authentication-entities. Very possibly multiple authentication-identities of the same type. (e.g. GUID for my smartphone, GUID for my iPad...)
Your front-ends (whether web or app-based), use a defined API to authenticate a user; using whichever of the mechanisms that front-end supports.
In some cases (particularly the native app), the presentation of an unknown ID triggers the creation of a new identity. However, as someone pointed out, in this situation you should ask the user if they want to connect to an existing identity. They need to provide authentication as that identity (once) in order to establish that connection.
One other point, whatever the server uses to uniquely specify an identity should be a value that is never provided to a client. Clients only know about the authentication mechanism and its data. That is, the GUID/UUID, username/password,...
In addition to the techniques listed above, something like OAuth is more secure than a locally-generated GUID. Those are one of a: easily-determined or b: easily-lost. If the value is highly predictable (say telephone #) it is easily spoofed. If it is generated at runtime and includes a hard-to-predict value like the hash of the current time when it is first generated, then it must be stored on the device and can be easily lost if the device is wiped. Good GUIDs can be generated, but they are often very type-of-device specific. Things like device serial numbers retrieved from ROM, IMEIs,... This is readily doable. But, is a lot more specific-device dependent than I'd likely be comfortable with.
The biggest real hurdle I see in this whole approach is that it will be awkward to allow an existing device-only (no username/password) user to sit down at a PC browser and connect to his existing account.
Number 2 is good enough as base decision. Users hate registration ;) So ability to use service without registration is good idea.
You can use GUID/UUID to identify devise. And use it as anonymous login before user login.
But what to do if 2 (or more) people use 1 device? Or device will be losed, stolen?
I think no one of the points cover these cases.
I have no idea what kind of web service you architect so can't advise more.
One solution is with a biometric. If the mobile device has biometric sensor, such as a finger print reader, user will enroll biometric with the device (only- due to privacy issues) at the time of purchase. The applications can be written such that every secure transaction requires the user to authenticate the biometric.
This does not seem to be too far off. Motorola Atrix has a fingerprint sensor...
Related
I followed this tutorial. https://hyperledger.github.io/composer/latest/integrating/call-out
Once I authenticate with Github I get a cookie that has a key called "userId".
Is it a good practice to use that key as the Id of a participant ?
That way I can sign up users in my backend easily via Github.
Think of a Participant as an actor in a business network. A participant might be an individual in an organization or it can be a role depending on the requirement (with multiple identities mapped to it but which are trackable nonetheless). A participant has an issued (or indeed already existing) identity mapped to it in the business network (you've seen how certificates are issued by an Org's CA etc).
As for good practice - the question whether it compromises anything, by using the user ID as a participant identifier or other field in its class (ie does it reveal anything to others on the business network, eg from other Organisations in the business network, that they should not know). You would be the best judge of that (and others here may add to this), but it sounds like it may be an approach that works for you.
I've been stumbling around for a few hours trying to understand Cognito and identity management in a mobile app. I'm relatively new to mobile app development. I've made a mobile app before, but never one with a back-end. so now I'm playing around with AWS intending to try just that.
I want to make sure that each user using my app can be uniquely identified so that I can store content that they submit to the server associated with them. But I also want other users to be able to see their submitted content. I haven't decided on a data storage mechanism yet (Amazon seems to offer a few), but whatever it is will have to be an indefinitely free service since I'm not planning on spending (or earning) any money on this app.
Part of what is confusing me is the need to create App IDs with whatever service I wanted to use with federated identities. I am starting to suspect there are multiple kinds of identities that I'm getting confused. Does the App have its own identity independent of a user's identity? I didn't expect to have to create Google and Amazon App IDs just to allow users to log into my app using their Google or Amazon accounts. I suspect I'm understanding the API wrong, and I'm having a really hard time finding applicable sample code usable from Xamarin.
I have this much code (unique identifier x'd out):
CognitoAWSCredentials credentials = new CognitoAWSCredentials(
"us-east-2:xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx", // Identity pool ID
RegionEndpoint.USEast2 // Region
);
And that seemed to run (in a debugger) without throwing an exception at least, but I'm not clear what it has given me. I'm doubting that this credentials object uniquely identifies the user after they might reboot their device, and start the app again the next day. For that I suspect I need something more, and I'm not clear what. What's the next simplest step to get a unique identifier for a user which I can store along with their content to associate it with them?
Are you set on having users use third part identity or do you want to provide user's their own identity? For federated identities (3rd party) you need to provide an Identity Pool ID which is created in Cognito to identify the federated identity provider. For your own identities in Cognito you create User Pools which also have an ID.
If you want to provide user sign-in and sign-up you want to use Cognito identities and not federated identities. The link below has some good references regarding this -
https://aws.amazon.com/cognito/dev-resources/
I'm building a nutrition skill and I want to include some calculators. I could have Alexa ask for the parameters each time something is calculated, but I'd prefer to have users set up a basic profile for themselves to store age, height, and weight values.
I found a small section of Amazon's documentation that talks about how the userId element could be used to store attributes across sessions. Will that work for what I'm talking about though? Or will I have to add OAuth?
There are two way to do this:
1) You can use sessions.
In this method, your data will be vanish when session is end (user stop talking with your skill)
more details https://developer.amazon.com/public/solutions/alexa/alexa-skills-kit/docs/alexa-skills-kit-interface-reference#session-object
2) You should implement an oauth 2.0 server to store user data. It is not that easy but you can find some oauth server example in here https://oauth.net/code/
For connecting your skill to your oauth server, you can follow here
https://developer.amazon.com/public/solutions/alexa/alexa-skills-kit/docs/linking-an-alexa-user-with-a-user-in-your-system
bonus: If you do not want to implement an oauth server, you can use Login with Amazon (or login with google) services. But you will still need a database server to store data
The userId that you get on your requests uniquely identifies an Amazon account, not a person. Despite the option to switch between different accounts on a single device (see: https://www.amazon.com/gp/help/customer/display.html?nodeId=201628040), the feature to identify people has been discussed (http://time.com/4683981/amazon-echo-voice-id-feature-2017/) but it's not available yet.
As already mentioned in the comments, you will need to persist the session information between sessions and you could use the userId to identify each account.
But in any case, you don't need account linking or using Oauth to simply identify a person.
Additionally, I'd recommend you to stay within the Amazon ecosystem and run your stuff in Lambda (with free tier and with development credits for developers publishing Alexa skills).
If you need help getting started, I have a single-file template for Alexa skills using Python and several examples:
https://github.com/josepvalls/ask.py
I have an application that is run on multiple user systems, and using OAuth, allows the users to log in via Facebook, Twitter, etc. The entire point of the user logging in is to get settings and actions that the same user made while logged in on other computers, as identified by logging in with the same OAuth provider + provider user id. The application itself is written in C++ using Qt.
My question is this: how can I save the settings that a user made, and allow them to retrieve it in a secure way? I have a centralized server that I can store information using MySql tables, but I'm not sure the best way to have the user application prompt the server, and receive the data stored for that user.
Any ideas or places you could point me towards?
There are several ways I could think of with this, all have trade offs:
Generally I would store the data in mysql using some kind of string or object encryption/serialization method. I do not use Qt much but http://qt-project.org/wiki/Simple_encryption has some examples of very simple encryption that could be used.
Then the question becomes: What do you use as the key? I would go either with the key provided by OAuth for that user (which could be an issue if users de-authorize the app but still want access to this data) or some other user provided key (which is counter to using OAuth in the first place).
Another option is to go with Qt Users session http://qt-project.org/doc/qt-4.8/qtwebkit-guide-cache.html
This would maybe remove the need to encrypt since it should only be accessible within the users scope.
NOTE: Based on comments below it seems the issue is more about securing communication with the MySQL versus the data inside of MySQL. Waiting on user comments to revise my answer.
I'm writing a Facebook canvas webapp that performs a login (using urllib) to a third party website and performs actions on behalf of the user. This means I have 2 accounts; the account the user has with my webapp (via facebook) and the account the app uses to perform a login on their behalf (with user/password details provided by the user).
I obviously don't want plaintext passwords in the DB. But I also don't want the user to have to enter their password every time they perform an action. I want them to enter the password once when they sign up, and I want to encrypt the passwords, but what do I encrypt against?
Any key on the server would be available to anyone who had gained access (i.e. useless), so I was thinking of encrypting it against a value available via the Facebook API.
When the user logs in (and gives the app their access token), the app can request the value via the API and encrypt/decrypt their 3rd party password with this. Anyone with access to the server wouldn't be able to make this request without the user being logged in to the app. (This still means someone snooping on the server could get logged-in users 3rd party password, but anyone who got one-off access to the DB couldn't see passwords.) Is this wishful thinking?
You might as well encrypt it using a key on the server. If anyone gains access to your server they will have everything they need to retrieve the key even if you're getting it from Facebook.
I think the best you can do is to store the key in a location that isn't available to your webserver, but that is available to your script. At least make sure you don't store the key in the database.
Whatever you do beyond that would just be security through obscurity. The key here is to keep your server secure so that no one gains access to it.
I guess you could store the logins ONLY on the client, in some sort of local storage and do all the actions related to the third party, from the client in JS.
This of course would need some change in the architecture of your app if you tought to do all this from your server, but that would possible for sure, you can event make client JS send data to your server after it worked so you can log data from the interactions with the 3rd party.
Furthermore it has the advantage of distributing the load on the clients
I know you didn't tag the question with javascript and you seem to want a server pure solution, but It seems the best solution to me. the user keeps its data ..
Security through obscurity might be your best bet. Perhaps implement an algorithm to generate the key using something standard (like the current datetime). You can store the date in your db, and use that to generate the key using your own algorithm.