View source for YTMND:API:Authentication and Remote Data Storage

In some cases applications may want to authenticate YTMND users or store preference data for users without the need of hosting their own database. While these things aren't currently available in the API, this page is for the discussion of what would be the ideal setup for doing so.

=== Example of authentication need ===

You have an application in which you need to store a preference for a YTMND user who is using your application, but you want to make sure the user who the preference for is actually who they say they are. Using a trust system would mean that anyone could change any other user's preferences without them knowing about it.

== In the Interim == 

If you have an application which needs to authenticate a user, one method would be a "nonce". 

If a user of your application needs to authenticate themselves to you, the following method is currently available:

# Have your application pick one of the user's sites at random.
# Generate a random string of text or a large numbers that is unlikely to be used.
# Ask the user to put the random string of text in the description of the randomly selected site.
# The user can then comply with the request (if they are who they say they are) and tell your application they have done so.
# Your application checks their site description for the random text, if it is there, the user is authenticated and your application can proceed.
# Once complete, the user can go back and remove the random string of text from their site's description.

This is somewhat secure albeit a bit painstaking for the end user, but it should only need to happen once.

== In the future ==

=== Authentication System ===

It's possible a feature could be added to YTMND to allow a user to add an "auth key" on their options page and then make that key available to anyone via the API. If a strong need for this arises, it should be discussed further.

=== Preference Storage System === 

In the API Roadmap is a system for storing bits data for users remotely which applications could use (this would allow server-less applications that need to store data to work from anywhere that can access the API). This is most likely a long way off unless the API is highly utilized.