(continues from Part I ) You can consider this post and the fine grained analysis we made in Part I as a down payment for grasping the implications we'll see in Part III, which I plan to post in few hours (almost done). I was planning to have just 2 parts, but it came out far too long and I need 3 :). Here we'll see a very general architecture that can support the traditional authentication practice we described so far. Let me refresh your memory with those few key points we established last time: When we feel the need of authenticating users before giving access to our application, usually that's because we need the answer to some questions in order to execute correctly the service we are offering The question "are you a returning user" can be verified directly by using some mechanism, such as asking to the user to submit credentials . For almost all other questions we need to get an answer that satisfies us without a chance of verifying it directly in-band (messy, but if you read part I you'll understand) When we authenticate a user in "traditional" way, we essentially do three distinct things at the same time: We answer the question "are you a returning user?" by verifying the credentials We link the credentials to a profile in our archive We "dehydrate" that profile, and we use its content for answering our other questions We'll now review what are the architectural components that we customarily use for traditional authentication, that is to say what do we need for performing Read More...