In order to login to most websites you need a username and password which is often stored in a SQL database. You are storing per-user information that can change, this is state. Can you prove that someone has the rights to access your system, such as an administrator or a user, without the need to store per-user state?
Asked
Active
Viewed 2,452 times
9
-
1Can you provide some more context to motivate the question? Do you really want to authenticate (which implies knowing at least a username), or to simply authorize an action? What sort of state do you want to eliminate - just the password, or also the username? What about state on other servers (like Identity Providers, Kerberos systems etc) – nealmcb Mar 31 '11 at 19:20
-
authentication without state... well http is a stateless protocol so I guess session and cookies is as good as it gets – WalterJ89 Apr 01 '11 at 03:31
-
I don't understand the question. If you want stateless authentication, then just have the client send the authentication credentials with every request. – Mark E. Haase Apr 06 '11 at 13:39
3 Answers
16
To some extent, you can offload state on the clients. You encode the access rights of a user into a blob to which you add a MAC computed with a server secret key. The blob-with-MAC is then sent to the client. Later on, the client comes back and shows the blob; the server verifies the MAC and thus makes sure that the blob is legitimate. This maps reasonably well on HTTP cookies. Possibly, the blob could contain some encrypted data (there again with a server-only symmetric key) if the server wants to store some user-related data without making it visible to the user.
Trouble begins when you want to revoke or change rights. You cannot prevent a client from showing a stale blob. This can be coped with by using a combination of expiration dates (the blob contains a date and is valid for, e.g., one week) and, if need be, revocation lists (the server knows a list of blobs that it must reject, even if their MAC looks good -- this is state, but not much because the wide majority of access rights do not get revoked).
If the entity issuing the access rights (the one which creates the blob) and the entity verifying the access rights (the one which verifies the MAC) are not the same, then you need to replace the MAC with a digital signature scheme.
Thomas Pornin
- 320,799
- 57
- 780
- 949
-
-
Kerberos is fine but does not really solve your issue: there is still some state "server side". What Kerberos does is that it allows that state to be located on dedicated servers which are potentially shared between several applicative servers. – Thomas Pornin Mar 31 '11 at 12:21
1
By using Kerberos the complexity that has to keep track of authentication state is isolated. The final step to access the service the client provides a Ticket which contains all of the state required to grant authentication to client. Asymmetric cryptography allows for this complex handshake without requiring communication between the three servers. The print server at the end doesn't require a stored state or database of user's credentials.
rook
- 46,916
- 10
- 92
- 181
-
1
-
-
The ticket is a way to offload state onto a trust model. The resource and the client trust the ticket to provide correct approval based on state held by the authentication server and ticket granting server. – Rory Alsop Mar 31 '11 at 08:26
-
@Rory Alsop, correct. I still think that you need state in order to have authentication. In my opinion this is very similar to Thomas Pornin's post, but its a proven solution. – rook Mar 31 '11 at 18:53
1
you can go down to hardwire admin- and user-rights on a system, allow admins only local access and anyone else any user access.
would be kinda chaotic, though.
imageboards (wakaba, futaba, &c.) have a kind of a token which gets crypted and displayed next to the users nick, so people can prove who they are.
users on such sites don't have much rights besides posting, though - also, it is not less chaotic.
kuhkatz
- 149
- 1
- 4