Now that we know that our communication has been secured,

we can discuss authentication and authorization methodologies.

In the world of secure web applications, proper authentication and

authorization are critical techniques you must master

in order to protect your systems and users data.

First, we'll walk through the steps and

mechanisms involved in authentication before moving on to authorization.

The first step in authentication is to

initialize the authentication mechanism itself.

This is the handshake that verifies with whom the serving is communicating.

This handshake can be accomplished in different ways.

Handshake number one, key based authentication,

such as a user name and password.

This can be in the form of any unique identifier, the user name, and

a client known secret, the password.

This gives you full control over the login process.

[SOUND] This is a completely valid process to use.

However, you now have the burden of keeping these details secure and

away from attackers that would expose those credentials and

publish them for the world to exploit.

We'll talk about some best practices in just a few minutes.

Handshake number two, OAuth.

Both OAuth 1.0 and OAuth 2.0 are advanced authentication protocols that are used by

many popular services such as Google, Facebook, Twitter, and GitHub.

A website will request authentication from this third party service.

Then the logged in user will verify that they wish to share those details

with this new site.

Handshake number three, single-sign-on.

Instead of being per site, the single-sign-on mechanism is often used in

enterprise environments to authenticate the same user on different portals or

organization sites over the same browser session.

In essence, the identification is passed from one application to another

without the user having to initialize anything manually.

This initialization step is technically the only step required for authentication.

HTTP basic authentication works by using only this step.

It sends the user name and password with each request.

This technique is most often used to grab data through a single request.

If you want to keep a user logged in throughout your site,

you'll also need to follow step two, which is to store the identification of that

user on the user's machine, most often referred to as the client.

Step two, store the identification.

There are two main ways to store the identification of the client browser,

sessions and tokens.

In session-based authentication, the server does all the heavy lifting.

After the client authentication from step one,

the server passes a unique identifier to the client.

This session ID is typically stored in a cookie and

attached to every subsequent request.

This session ID is just an identifier, and the server does everything else.

Associates the identifier with a user account.

Restricts or

limits this session to certain operations or a certain time period.

Invalidates this session if there are security concerns.

Logs the user's every move on the website.

I want to point out that sessions can be used to track website visitors without

authenticating them to a specific user.

In token-based authentication, no session is stored on a server.

After the client authentication from step one, the client receives a token.

This token not only provides a means to identify the client, but

it also stores additional user information.

Tokens can also be distributed to external applications

as a form of authentication across multiple domains.

Another advantage of using tokens is the ability to revoke tokens at any time,

and thus restricting access once more.

You should create a separate token for each application.

Tokens are used for both OAuth and single sign-on.

Additionally, you can use tokens even if you write your own authentication.

The most common implementation is through the use of JSON web tokens, or

JWT, pronounced jot.

A JWT is available for use by any language and

is covered in depth in other Treehouse courses.

Check the teacher's notes for more information.

The complexity of authentication is apparent.

We need to choose the right implementation strategy, the types of libraries we

will use, and how we will store the data we use for authentication.

If you're trying to quickly build an application and you don't want to worry

about the issues that come with storing user credentials, then using a third

party login service such as Facebook, Google, or GitHub is a great choice.

If you need to control the login process more in depth,

then it's completely fine to store your own credentials, but

you now have the burden of keeping those credentials secure.