Ok, so not only can you utilize a oAuth2 / chatter license authentication system to authenticate users on your site to SF and provide your application with a session limited access token to data scoped to the user that just logged in, you can also do the following:
Utilize an api (only) account that maintains a constant connection between your application and your Salesforce org. This is accomplished by using a server-side oAuth flow and will establish a set of credentials your application can utilize to query SF. Once you have established this connection your workflow would look like this:
End user visits website and enters credentials
Your application accepts the credentials from the user, and submits a query to salesforce using your previously established connection. It's important to note that you should probably construct this query to match on username AND password (hashed accordingly ... because you are hashing AND salting passwords, Right?) 0 rows = invalid password. 1 row = valid password, 2+ rows = you're doing hashing wrong.
At this point, you've now established that the end user is, (or is not) in possession of a valid username and password which, if you've done the query right will also give you the Id of the object you were querying. I'm assuming that you'll want that Id to do other kinds of work.
All that said -- THIS IS THE WRONG WAY TO DO IT, PLEASE DON'T DO THAT. --
Let me say that again. -- DO NOT DO IT THE WAY DESCRIBED ABOVE --
To do so is to leverage almost NONE of the platform's rich and vibrant feature set, it's security and permissions features and is incredibly limiting, and prone to data-f'd-up-ness.
If you are building an application where users will be allowed to login and then access Salesforce data, let salesforce be the manager of Identity and Authentication and piggy back your application on it. In the inspiration question, the user should oauth each user to SF, and accept the salesforce asserted identity id as a FK lookup to the local user table. Ie: SF user abc1234567890defgh returned as part of the oAuth hash is matched to local user 'Awesome User'. That oAuth access token should be used for that users' data access.
Yes, this requires a change in thinking and architecture, but is safer from both a security and data sanity aspect.