Architecture for Authentication/Authorization of Mobile and Web Users

Question

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

1. Mobile users must be able to use the native application without a login, including for contributing content (marking favorites, uploading photos, etc).
2. Mobile user should be securely and uniquely authenticating to the web service even without specifying account credentials.
3. Mobile user may have multiple devices, which will be unaware of each other.
4. 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.
5. It should not matter whether an account was created on mobile or web.

Architectures Considered

1. 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
2. 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?

Answer 1

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.