These are rows in a database table somewhere which are the authentication standard for an application where traditional sessions cannot exist, i.e. ASP.NET Web API-driven applications. When attempting to do anything the user must hand in the guid for a row and the row must be found. This, yes, means that the rows must be cleaned away periodically (in short periods) by a background process least they linger for too long and that it is probably wise to hand in a second guid for a user's ID also so that attackers cannot easily play guess-the-guid. Perhaps the two guids are just a part of a greater packet for communication wherever applicable. Such packets would take different shapes for differing functional roles in different API calls. The initial log in of a user would have to create a record and hand back to the user the id for the session.
No comments:
Post a Comment