Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <h2>Once upon a time, somewhere on the Internet....</h2> <ul> <li>Browser: "hey, can I see this web page?, Trouble is, I don't remember speaking to you before"</li> <li><em>Website: "sure, fill in the form, I need your username and your password"</em></li> <li>Browser: "Here ya go"</li> <li><em>Website: "Great!, Welcome back koldfyre! Here's the page. Look, if you want more pages, take this token and use it when you ask for another one"</em></li> <li>Browser: Cool. That site gave me a token. I'll memorize it!</li> </ul> <p>A few minutes later</p> <ul> <li>Browser: "Ooh! Can I see this other web page? Here's my token"</li> <li><em>Website: "That token looks good, hello again koldfyre, here's your web page"</em></li> </ul> <p>That, in essence, is it. In order to remember a user has logged in, it gives the user a token which it must present with its next request. This is normally achieved by the server telling the browser to store this token in a cookie.</p> <h2>Delving deeper - transport layer authentication</h2> <p>The way the credentials are passed to the server, and the nature of the token it returns, vary depending on the authentication method employed.</p> <p>The very simplest, <a href="http://en.wikipedia.org/wiki/Basic_access_authentication" rel="nofollow noreferrer">HTTP Basic Authentication</a>, is provided by most web server implementations. It causes your browser to pop open the familiar login dialog box. The "token" is simply your plaintext username and password base64 encoded. Not particularly secure.</p> <p>A server might also provide <a href="http://en.wikipedia.org/wiki/Digest_access_authentication" rel="nofollow noreferrer">Digest Authentication</a>, which avoids transmission of the actual credentials - the client instead generates a hash of their credentials with a server generated salt. It is designed to prevent password sniffing and replay attacks.</p> <h2>Deeper still - application layer authentication</h2> <p>For maximum flexibility and control, most sites opt to implement the authorization in the application layer rather than the HTTP transport layer. This gives a wider variety of security choices. Any site which asks for credentials in a web page (rather than the browser's login dialog box) is using a custom authorization method.</p> <p>Custom methods will vary wildly in their initial interaction, but they almost always result in the user being given a session cookie containing a randomly generated identifier. The browser then automatically presents the cookie with each subsequent request. The web application will inspect the cookie value to ensure it is still valid.</p> <p>It's also possible to hand off the authorization to a trusted third party, generally to provide some sort of single-signon service. In cases like that, when you notice a user isn't authenticated, you bounce them off to the authentication provider. They authenticate them, and they will be returned to you with some kind of token you verify with the provider. <a href="http://en.wikipedia.org/wiki/Shibboleth_(Internet2)" rel="nofollow noreferrer">Shibboleth</a> is one example of this. You also logged into this very site using a similar method employed by <a href="http://en.wikipedia.org/wiki/Openid" rel="nofollow noreferrer">OpenID</a></p> <h2>Further reading</h2> <p>Here's some nice answers from <a href="https://stackoverflow.com/questions/549/the-definitive-guide-to-website-authentication-beta/477578#477578">a similar question</a></p> <ul> <li><a href="https://stackoverflow.com/questions/549/the-definitive-guide-to-website-authentication-beta/477578#477578">PART I: How To Log In</a></li> <li><a href="https://stackoverflow.com/questions/549/the-definitive-guide-to-website-authentication-beta/477579#477579">PART II: How To Remain Logged In - The Infamous "Remember Me" Checkbox</a></li> <li><a href="https://stackoverflow.com/questions/549/the-definitive-guide-to-website-authentication-beta/477580#477580">PART III: Using Secret Questions</a></li> <li><a href="https://stackoverflow.com/questions/549/the-definitive-guide-to-website-authentication-beta/477583#477583">PART IV: Forgotten Password Functionality</a></li> <li><a href="https://stackoverflow.com/questions/549/the-definitive-guide-to-website-authentication-beta/477584#477584">PART V: Checking Password Strength</a></li> <li><a href="https://stackoverflow.com/questions/549/the-definitive-guide-to-website-authentication-beta/477585#477585">PART VI: Much More - Or: Preventing Rapid-Fire Login Attempts</a></li> <li><a href="https://stackoverflow.com/questions/549/the-definitive-guide-to-website-authentication-beta/477586#477586">PART VII: Distributed Brute Force Attacks</a></li> </ul> <p>Other answers in that question provide even more links to round out your education!</p>
    singulars
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. This table or related slice is empty.
    2. VO
      singulars
      1. This table or related slice is empty.
    3. VO
      singulars
      1. This table or related slice is empty.
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload