Welcome to the first entry of my for Newbies series where we go through technical concepts from the point of view of the uninitiated. The idea came to me when most guides / tutorials usually leave a lot of things unexplained, which can leave some readers feel lost when trying to learn about a new concept they are learning for the first time! So without further ado let's start.

Authentication and Authorization

When it comes to web-apps, programs, mobile applications, websites... the concepts of authentication and authorization are not necessarily a need to know. When you don't need it you don't need it, simple as that. These concepts only come into play once we want restrict or define rules on what you can do.

Authentication ≠ Authorization

One important thing you must understand that there is a difference. These are related concepts but still define two different things:

• Authentication defines the act of verifying the identity of a user.
• Authorization defines the act of verifying what the user is allowed to do.

It's easy to mix up the concepts and you will see these definitions being used interchangeably online. Some of it is by mistake but in a lot of cases these concepts are so related and intertwined that people use it to mean both. Don't do that.

Why?

Before we go further let's look at the why. Why do need this or do this? We want to make sure that we don't have a wild west approach with our systems. Look at these concepts as laws to govern what the user can or cannot do. Or whether the user is allowed to do it in the first place.

When you login to something, you are authenticating yourself to that particular application/website. When you are logged in you have information tied to it, some of this information should only be accessible to you. In other cases there are actions that only you should do. For example liking a Instagram post. Only you should be able to do that because you are authenticated to do so. If there is a private account, you are unable to view it because you are not authorized to do so.

OAuth 2.0

It's good to note that we are talking about OAuth 2.0 it means that we talking about a user flow where when you sign-in/create-an-account on a website/application through another system. For example when you visit a website that offers you to login via your google account. See the image below for this flow:

This image might look a bit complex right now but don't worry, we'll get back to it later on.

Before we had OAuth 2.0, there was not a clear set of rules or guidelines regarding how to implement such a thing. How do you let this website log-in for you on behalf of Google? If you were to type your actual google username and password directly on the website you are basically giving away your keys to someone else!

It's important to understand one thing before we go further: OAuth 2.0 is a specification regarding how we allow systems to be authorized to access other systems. OAuth 2.0 is not an authentication specification! But it does contain authentication as part of its process.

The point of OAuth 2.0 is to standardize and an approach to this problem and to also prevent security issues as described earlier.

Tokens

An important part of understanding these concepts are tokens.

Tokens are used to transfer secure and sensitive information. Usually when we talk about tokens in web development we are talking about JWT’s (Json Web Token).

JWT’s consist of three parts:

Header	Payload	Verify Signature
Mentions the type of token	The actual information of the user	Used to verify the authenticity of the token

The Payload contains most of the information that will be relevant. For example:

• Token expiration date/time
• Token creation date/time
• User specific information
• Scopes & Claims Definitions of what the token is trying to access

If you got yourself a token you can few the details of it easily by using a parser. A popular online one is https://jwt.io (opens new window)

Simple flow

So let’s go more in depth on how OAuth 2.0 flow works. Remember that chart from before?

Let’s define the actors to this flow:

• The client
• The resource owner
• The resource server
• The Authorization server

The client is the application the the user is using. The client initializes the the flow, it’s through the interaction of the user with the client which causes a redirect to the authorization server.

On the authorization server is where the user fills in their credentials to authenticate themselves. Usually it follows up with a prompt to allow the requested application (client) to be granted to certain information (scopes).

Following this the user gets redirected back to the application. With the redirect we also receive an authorization code. This is not the token yet. We need this code to retrieve the token! On the client application we need to pass the code to authorization server, which will then respond with an access token.

The access token is what we use to perform the requests to the resource server. With this token we can retrieve the information of the specific user. The server will then validate the tokens and then depending on it being successful or not, give us the information we are requesting. So at the end we do this:

Further reading

It might be a lot of information in the beginning, it is, but there is much more touch on. Hopefully with this introduction you have a better understanding on what is going. Look forward to future articles handling specific concepts such as JWT tokens or applying this to a working applcation/website!