7 Authentication Concepts Every Developer Should Know

Before a system can authorize or restrict anything, it first needs to know the identity of the requester, whether it's a user accessing our service through a browser or through mobile app, or it's a third-party service trying to access our system. That's what authentication does, it verifies that the user or service trying to access our system is who they claim to be. But here is where most software engineers confuse or mix up concepts. They mix up authentication methods with authorization frameworks. They treat JWT as an authentication method, when in reality it's just a token format. They also confuse the bearer authentication with JWT. They sometimes call OAuth2 an authentication method, when in reality it's actually an authorization framework. And they mix up single sign-on with authentication methods, when it's really a user experience pattern. In this video we're going to fix all of that by covering first of all what authentication is, and then all the major types of authentication, starting from basic to digest authentication, to API keys, sessions and cookies, bearer authentication and JWT tokens, what are access and refresh tokens, also we'll cover OAuth2, OpenID Connect, also single sign-on and identity protocols, and understand what each one actually is and where this all fits. Let's first understand what is authentication and then we'll get into the different authentication methods. So authentication really answers one simple question, which is who the user is, whoever is trying to access our system. Let's say you have your system like your API gateway, the layer of APIs, then your service layer, and also the data storage. Before anyone can make requests to your API gateway and start accessing services and data, they first need to be authenticated. That is where they send a login request. This comes either from a user or another service. This is where we confirm their identity, if it's valid, and grant access to our system, to our API gateway, and all the other services. Or if the identity is not confirmed, then we reject it with a 401 unauthorized response. This is the first step before they will get into the authorization, which is what they can access and what they can do once they can sign into your system. But that's a separate discussion in itself. So in this one, we are primarily focusing on the authentication and different authentication methods that we can use to verify the user's identity. Now let's see the different authentication methods that we have to verify the identity of the requester. And let's start with the basic authentication methods. These are the basic auth, digest authentication, API keys, and session-based authentication. Let's start with the very first one on the list, which is the basic authentication flow. This is the simplest form of authentication. Let's say you're making a request to the server to access some resource like API users to retrieve the user data. You will first receive an unauthorized response because you didn't provide the credentials. So we prompt the user or the service to provide credentials before accessing any resource in the server. So in the upcoming request to the same resource, they also provide the authorization header. And this header contains the base64 encoded version of the username and password for this user. This is where we verify it on the server side. If the credentials are valid, then we respond with 200 okay status with the user data returned in the body. Or we unauthorize it again, marking this as credentials invalid. The problem with this method is that base64 is easily reversible. So this is an insecure method unless it is wrapped with HTTPS protocol. And even then, it's rarely used nowadays in production outside of the internal tools because you're sending the credentials with every request and you're sending the base64 encoded version, which is not that secure. That's why we also have a digest authentication, which is slightly better. And it uses the MD5 hashing. So this method works similar to the authentication with basic version. So you are, let's say, trying to access the same resource like the users. It will first respond with 401 unauthorized, prompting you to include the credentials. And then you'll make the same request, but with the hashed response. And that will also contain the MD5 hash version instead of the plain password and username. And same process as the previous one. If the credentials are invalid, you will receive 401 unauthorized. Otherwise, you will receive the successful response with the user data in the request body. This is slightly better than the basic auth as it uses the MD5 hashing, but it's still outdated and rarely used today because we have better options, as you will see soon. And if you're wondering, how do we set these options in the authorization? For instance, if you're making the request from Postman, or if you're doing this from the code, then you'll include it as the header in the request. This is where you can set the authentication type. And you will notice the things that we are discussing here, like the basic authentication, which was the first version, or digest authentication, which is the second version. And you will see the other methods available here, also the API key option. And Postman calls all of these authentication types to just keep it simple on the interface. But that's also one of the reasons why developers get confused. And they think that all of these are authentication types, when some of them are authentication methods, some of them are authorization frameworks. Next, we have API key authentication. This is where you generate a unique key for each client, and then they send it with each request to access the resources. So for the same request, as we discussed, it comes to your API server first. And it will include either authorization header or XAPI key. And that will include the API key that you generated for the user. These API keys are typically stored in a database with the key hash and also the scopes for the API key. And for instance, if you ever tried to access APIs by generating a key on the dashboard, and then it gives you the key back, which you can attach to the requests, that is where you already used the API key of that service to access the data. So if you included that key in the request, then the server will first do an API key lookup in the permissions or users table. And if it's able to verify that the API key is valid, then we will authorize the request and send the successful response with the data in the response body. Otherwise, the user will get a 401 unauthorized response. And if the key is missing overall, like the authorization header or XAPI key, then we just return a 400 bad request because the API key is required to access this type of system. One issue with API keys is that if the key ever leaks, then anyone can use it and start accessing the resources on your behalf with your API key. And there is no built-in expiration unless you implement it yourself. Another thing is that this might seem similar to JSON web tokens, but API keys are just random strings with no embedded information, while in JWT we can store also information, as you will see shortly. So the server here has no way to know who owns the key or what permissions they have without looking it up in the database. Next, we have the traditional web approach, which is the session-based authentication. This is where a user logs in with their credentials and then we create a session in some sort of session storage. This session storage can be as simple as just in-memory, like just a variable, but the problem here is that we will lose it once the server restarts or crashes. The other option is we can use tools like Redis, which is one of the most common ones in production, because it's fast and it supports expiration for the sessions. Or we can use a dedicated database here, like SQL type of database. Another option, which is very rare, is to use the file system of the server that you're using. The problem with this one is that it's not scalable and overall, Redis is usually the go-to for production because it's fast and has built-in key expiration. So with the first request, we are fetching the session ID and then we set the session cookie on the client side. Then for any other upcoming requests that contain this cookie, we look up the session in the session storage here and then if the session is valid, we will get back the user data and we will send it with authorized response. Otherwise, if it's not found, if we can't find the session, then this user is not authenticated, so we send them an unauthorized response. One challenge with session-based authentications is that it is stateful, which means that the server must remember the sessions. We need to have some sort of session storage here. And it works great for traditional web apps, but cannot scale as easily for APIs or distributed systems. Now let's look at token-based authentication. We'll cover bearer authentication, JWT tokens, access and refresh tokens, and how this compares to the session-based authentication. Instead of sessions, modern applications usually use tokens. So the client sends a token with each request. For example, we have a login with credentials, where user will include their credentials in the authorization header, which will include the type of authentication, which is bearer, and also the token, which we will validate on the server side. One thing developers confuse here is the bearer token and JSON web tokens. Bearer token just means whoever has this token gets access. So it's a pattern, but not a specific method. And the most common type of bearer token is JWT, JSON web token. It's basically a signed JSON object that contains the user ID or email for us to validate the user, also expiration time, and other claims as we need to store them, like roles, permissions, and so on. So what we do on the authentication server is we validate the credentials once we receive that authorization header. And it is stateless, meaning that we don't need a database here to look up, and that is why it's also scalable compared to the session-based authentication. Before the JWT, let's say, revolution, a token was just a string with no information. And that token was sent, and then this was looked up in some sort of database, and only then we could verify that the user has access. The downside of that was that, of course, it's still stateful, because we need the database access or cache, which is required every time the token is used. With JSON web tokens, now we can encode and verify via signing their own claims. And this is what now allows us to issue a short-lived JWT tokens that are stateless, meaning they are self-contained, and they don't depend on anybody else. They do not need to hit the database, and this reduces the database's load, and it also simplifies the authentication process for the server. So the first time we will receive the credentials and validate the user. And if it is valid, we will generate the JSON web token and send it to the client. From this point forward, the client can make requests and include this bearer token, which is this authorization header that contains the bearer authentication with the token. And that token is, in most cases, it is a JSON web token. We verify that signature locally, without needing to hit the database. And if the token is valid, we return the requested data. Otherwise, we return an unauthorized response. Modern systems also use two types of tokens. One of them is the access token, and the other one is the refresh tokens. The reason we need two tokens here is that access tokens are short-lived, and they are used for API calls to the server, while the refresh tokens are long-lived, and they are used to get new access tokens, basically to renew the access token. Whenever a user sends a login request and signs in, they get both of these tokens. We generate an access token that's valid for 15 minutes to one hour, and we generate a refresh token that can last for days or even weeks. Clients now will use the access token to access the API and make the requests, and it also stores the refresh tokens. One important note here is that we never store it in local storage, but we store it in HTTP-only cookies. This prevents us from XSS attacks on the client side. And after this, user will stay logged in without re-entering credentials. If their access token expires, they will get an unauthorized response, and this is where we will use that refresh token which we stored to generate a new access token on the OAuth server side. We can make a request with that new token, and this will successfully return us the data since we renewed the access token. Next, let's get into OAuth 2.0 and OpenID Connect, which are some of the misunderstood concepts, and let's clarify whether these are authentication methods or authorization frameworks and how they work. OAuth 2.0 is one of the concepts that is often misunderstood. It's an authorization framework and not an authentication, so it answers what can this app access on behalf of the user. For instance, if you want to grant an application access to your Google Drive to be able to read your files from there, you would typically connect your Google Drive for this external application, and you're giving the app permission to access your data. The way it works is it first will redirect you to consent screen from the Google OAuth authentication, and it will show you the permission request. And if you allow access for this application to be able to read the drive files on your behalf, then it will return the authorization code to this external application, or it can also be your application. And the way it works after that is that you exchange the code for token, and you return the access token from Google OAuth to be able to read the data. That is the confusing part, because you're getting back an access token for the Google Drive API, and you might think that this is an authentication method, but the access token just proves that the app can access your resources. But it doesn't tell the app who you are, it just proves that the app is allowed to access certain resources from your Google Drive. So after this point, the application will be able to request files with that token and return the user files from Google Drive API. Next, we have OpenID Connect, which adds authentication on top of OAuth2. So when you click on sign in to Google, let's say, via your app, it will redirect you to the authorization endpoint. And this will show you the login screen where you grant access to sign in to Google through your application. If you enter your credentials and consent, then the provider will return the authorization code. And after this step, your application will exchange the code for tokens and return the access token in combination with the ID token. From here, the access token is for OAuth2 authorization, but the ID token is a JSON web token that contains your identity, which includes your email or username user ID. Which means that after this point, your application is able to verify the signature and extract the user's identity to send the ID token for verification to your backend. And by having this ID token, your application can now create its own session and grant the access token for that user. This is a modern solution. It's secure and also scales well. And that's also why most applications nowadays use that type of authentication, like sign in with Google, GitHub, Microsoft, and so on. And lastly, let's cover single sign-on and identity protocols. Single sign-on is a user experience, not an authentication method, which means that you're able to log in once, but access multiple services. For example, when you want to log in to Google or Okta, let's say you want to get access to your Gmail, to your Google Drive, to YouTube, to Google Calendar, you can do this by logging in once to the identity provider. Let's say it can be Google in this case, if you want to access these services. And single sign-on uses identity protocols underneath to validate these sessions. So once you sign in with the identity provider, let's say it's Google in this case, your global session is stored in a session storage. And then you get back a single sign-on cookie to your client to be able to access other resources. So let's say you want to access Gmail for the first time, then once you log in, you verify also the session, and now you're able to access Gmail. And for the next request, if you need to access Google Drive for the next one, you don't need to log in again, because you have this cookie and the session stored in the session storage. So we just verify your session, and if it's valid, then you get access to Google Drive as well. And similarly to YouTube, to Google Calendar, and other services. As I mentioned, single sign-on uses identity protocols underneath. And these protocols are SAML, which is Security Assertion Markup Language, or OpenID Connect. Both of these are identity protocols, which are used in combination with single sign-on. In case of SAML, to be able to access the app, you're redirected to login. And this is where we use SAML for authentication. This is a common solution in enterprise and legacy systems like Salesforce, corporate dashboards, and so on. It is an XML-based protocol. So once you want to sign in, you are redirected to login, and then you get back the SAML assertion in XML format. And after that, your identity is confirmed for the user, and now you're able to access the third-party application. SAML is still widely used, but it's an older version compared to OpenID Connect. So the next option is the OpenID Connect as an identity protocol. Let's say you want to access an app, and in this case, it's Gmail. You will be redirected to login to provide your credentials. And once you provide your credentials, the user is authenticated, and now you get back the ID token in JSON web token format. And this is what you will use for confirming your identity with Gmail. This is, for instance, what Google uses under the hood, and it's a more modern approach compared to SAML, but both of them are still very secure and relevant. These are the most common types of authentication, and that is just the first step for accessing our system. After you know who the user is with authentication, you need to also know what they can do and what permissions they have. That is the part of authorization, and I recommend you check out this video next to learn about the different authorization frameworks and how it works.