2

A comment below an answer about state and REST recently piqued my interest. For clarity I'll quote the comment in full:

Nothing in my answer implies a solution based on database access on every request, if you think it does, it is a failing on your part to understand authentication and authorization at that scale. The authentication can be implicit in the state, do you think that facebook does a "database access" on every request of its REST API? Or Google for that matter? hint: no

I tried to think how one might authenticate without checking a user-provided value against a centrally-held one, even if one to know what data to display to the user, and came up blank. i freely admit this is a failing on my part to understand authentication and authorization at that scale. My question is therefore: how do sites like Facebook and Google accomplish this?

Community
  • 1
  • 1
Garry Cairns
  • 3,005
  • 1
  • 18
  • 33

1 Answers1

2

One way is claims based authentication. Simplified and somewhat loosely interpreted, it boils down to this;

  • Instead of the server application authenticating the user itself, an un-authenticated user is redirected to a separate authentication server.

  • The authentication server validates the user in any way it wants to (login+password, certificate, domain membership etc) and creates a signed "document" with the relevant user info (user id, name, roles, ...) It then redirects the user back to the server application with the document enclosed.

  • The server application validates the signature of the document, and if it trusts the signature, it can use the document contents to assume who the user is instead of accessing the database.

  • Normally, the server application caches the document in a cookie/session or similar so that the next access to the application does not have to bounce through the authentication server.

In this way, the server application does not need to concern itself with how the user is authenticated, just whether it trusts the judgement of the authentication server. If the authentication server (and possibly the client unless it's a browser) adds Facebook login support, the server application will automatically "just work" with the new login type.

Joachim Isaksson
  • 176,943
  • 25
  • 281
  • 294
  • So it's not that a database isn't being checked, it's just that authentication is handled from a different database? As I understand your answer a user-provided value is still checked against a centrally-held one in a database, but this is done on a different server essentially for load balancing. Is that right? – Garry Cairns Dec 07 '14 at 14:22
  • @GarryCairns The difference is that the database is consulted _once_ at login to generate the claim document, and after that the database access is no longer needed to know the required user data, instead the claim document (or a session created from it) is used to look it up. If you're only using a single server, you could get pretty much the same effect by reading the user data once from the database at login and putting the result in a session, so that you don't need a database access to get - for example - the user name. – Joachim Isaksson Dec 07 '14 at 14:26
  • I'm a bit late, but hope you will still there to discussi it a bit more! Today i was thinking something similar, packing up credentials in a JSON, AES cripting them (key known only by servers ofcourse) and giving them back to users, but my concern is about loosing control upon those documents. I mean as long as there is access without authentication (they allready hold the signed document) there is no DB look-up and therefore if a user decide to logout (cause he thing someone may have stoolen this document) the document would still be valid. Should a fast expiration time solve it up? – Newbie Feb 03 '16 at 02:09