[erlang-questions] web authentication

[John Kemp]

Joe,

On Jul 18, 2011, at 3:13 PM, Joe Armstrong wrote:

> I'm still following this thread with interest thanks for all the information.
> 
> It seems like there are two phases:

There are actually (at least) three phases I can think of:

i) A person provides some claim (I have the email address me@REDACTED) which the authenticating entity may verify (by sending an email or phone SMS message, for example). This can involve the creation of a shared secret (password) known only to the authenticating entity and the claimant.
ii) Presentation of an identifier linked to this initial claim (account name, email address and so on) and the shared secret associated with the account identifier (your phase 1)
iii) Session-based authentication, achieved by means of a session identifier (rather than an account identifier and secret) and potentially session-limited secret - such authentication is of the variety "I claim that I am the same entity which authenticate to you 2 hours ago by means of the email address me@REDACTED" and usually accomplished concretely by a "token" (such as a web cookie).

> 
> 1) initial authentication
>    Here there is some kind of challenge/response interaction
>    If this succeeds the server sends a session cookie to the client.
> 
> 2) Per-connection authentication.
>    If 1) has succeeded, the client sends the session cookie to the
>    in each new request. The sever uses this as a key into a database
>    if the database lookup matches the correct user then everything is ok
>    This has to be done ever time a new socket is opened.
> 
> My original question also asked about openId - can't I get google (or something)
> to authenticate the user then do some kind of hand-over to me?

Yes, if you implement Google's (or Facebook's... and so on) protocol for making identity assertions about their users. OpenID isn't as much used these days as Facebook Connect and Google's equivalent protocol. 

> If this
> is the case then I wouldn't have to bother with the details of passwords myself

If you wish to rely on others to perform the actual authentication, and simply take indirect assertions of a user's authenticated status, that's correct. If you want to "know about the user", you may not get much (enough?)  information from Google, FB et al, without asking the user directly to provide it. Such protocols are usually only supported in the context of a web browser (not other kinds of apps) since the web redirect is a good way of establishing some reasonable correspondence between the user at one site and the user at another site ("the user at my site Y is the one redirected from site X" as long as site X and Y trust each other to do the right thing).

Cheers,

- John

> 
> Cheers
> 
> /Joe
> 
> 
> 
> 
> 
> 
> 
> 
> On Mon, Jul 18, 2011 at 6:22 PM, Tim Fletcher <mail@REDACTED> wrote:
>>> Logging out can be accomplished by simply sending an "unauthenticated" HTTP
>>> status code and a new Authenticate header that tells the client it needs new
>>> credentials.
>> 
>> Most browsers will cache HTTP Auth credentials until the end of the
>> browser session, so although it looks like you've logged out, you'll
>> often be able to get straight back in again without having to re-enter
>> a password. This usability issue is more significant a problem than
>> the overhead of SSL, IMO.
>> 
>> An alternative to storing session data on the server is to use signed/
>> encrypted cookies. Stefan Tilkov outlined a general approach for doing
>> this, which you can use in any language:
>> 
>>  http://www.innoq.com/blog/st/2009/06/devoxx_08_rest_patterns_and_an.html
>> (slide 44 of 71)
>> 
>>  - ask user for name and password if no cookie passed
>>  - authenticate user
>>  - create auth token as username + expiry date
>>  - hash(auth token + server secret)
>>  - return cookie as hash + auth_token
>>  - server validates with algorithm on in-memory data
>> 
>> Hope that helps.
>> 
>> Cheers,
>> Tim
>> _______________________________________________
>> erlang-questions mailing list
>> erlang-questions@REDACTED
>> http://erlang.org/mailman/listinfo/erlang-questions
>> 
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions