Hi from Tokyo Japan, and welcome to Jeremy’s IT Lab. In this video we’re going to cover REST API authentication. We’ve already covered the basics of REST APIs, but Cisco recently added authentication to the list of things you need to know about REST for the CCNA exam. APIs give access to an application and its data, so security should always be a major concern when designing and using APIs. In this video, we’ll examine some common methods of REST API authentication. But before we get started, let me take a minute to shill my books, Acing the CCNA Exam volumes 1 and 2. These books are up to date, covering everything you need for the latest version of the exam. REST API authentication, for example, is covered in chapter 23 of volume 2. I highly recommend using books in combination with a video course, and if you want my books, you can get them at the links on the screen now, or on Amazon. Now let’s get started. So, what are we going to cover in this video? First, I’ll introduce the concept of REST API authentication in general, including why it’s so important. Then, for the rest of the video, we’ll cover four common types of REST authentication: basic authentication, bearer authentication, API key authentication, and finally OAuth2.0. We’ll outline how each of these methods works, and their advantages and disadvantages. So, that’s the plan for today. Now let’s learn about REST API authentication. Hopefully you already know this definition from the security section of the course, but authentication is the process of validating the identity of a user or system to ensure legitimate access to resources. In the case of an API, the resource is the application and its data. In many cases, these resources should be protected. But without authentication, unauthorized users can send API requests, potentially accessing sensitive data or modifying the application. For example, here we have an application and some data. The API serves as an interface, allowing other apps to use the application or to access its data. Without authentication, if a malicious user sends an API call, also called an API request, the API will accept the request and provide the requested data. It’s worth noting that some APIs are intentionally open and don’t require authentication. These APIs typically provide publicly available data that doesn’t require security protection. But for many APIs, that isn’t the case, and security is a major concern. When the malicious user makes the API call, the API should authenticate the user, asking “who are you?”. If the authentication process fails, the request is denied and the user doesn’t get access to the data. Implementing a reliable authentication method like this is essential for protecting applications and data that aren’t meant to be publicly available. And in addition to security concerns, many APIs track usage for analytics and billing purposes. For example, charging customers according to how much they use the API is a common practice. A great example is the ChatGPT API. Many AI applications use ChatGPT behind the scenes, and OpenAI charges businesses based on token usage. Basically, a token is a chunk of text, either input or output, and this means companies pay more as they send larger or more frequent requests to the API. So, to summarize the previous slide, when working with REST APIs, authentication is crucial for verifying a client’s identity and securing access to resources. REST APIs use various types of authentication to achieve this, and we’ll cover some key ones in this video. These authentication types are also called authentication methods, or authentication schemes; those are the more technical terms. In this video, we’re going to cover four of them. The first method is basic authentication. As the name suggests, this is the simplest form of REST authentication. It sends a username and password in every request, encoded in Base64 format. Note that encoding is not the same as encryption; I’ll explain that in the next slide. Next, we have bearer authentication. This method uses a token, called a bearer token, included as an HTTP header in the request, to verify the client’s identity. This method is quite common in modern APIs; the client first obtains a token and then includes it in requests after that. Another common method is API key authentication. This requires a unique key, which is typically included as an HTTP header, like the bearer token. The API key acts as a unique identifier for the client, and is useful for tracking usage. Finally, we have OAuth 2.0. This is a more advanced and secure authentication framework that grants access using access tokens. OAuth 2.0 is widely used for delegated access and third-party authentication. I’ll break down what those terms mean when we cover OAuth 2.0 in detail. But if you’ve ever seen the “log in with google” option on a website, that’s OAuth2.0. Each of these methods has its own advantages and use cases. Now let’s look at them one by one. We’ll start with basic authentication, which authenticates using a username and password in the HTTP headers of each API request. Before we dive deeper into basic authentication, let's first break down the structure of an HTTP message so you can see where authentication fits in. It begins with what’s called the start line, which includes three pieces of information: The HTTP method, which is POST in this case; the URL, which is api/v1/acl/rules; and the HTTP version, which is 2 in this case. The POST method is typically used for a create operation; think back to the CRUD operations (create, read, update, delete) we covered in the previous video on REST. So, this HTTP message is probably a request to create something on the server. Next, we have the headers. These provide metadata about the request, such as authentication details, content type, and information about the client making the request. Often there are several headers; there are four in this case. The headers are followed by a blank line, and then there is the message body, the actual contents of the message. This is the HTTP message, which would then be encapsulated in a TCP segment to be sent over the network. This message is using basic authentication; can you find it? It’s this line right here. It uses the “Authorization” header, but the real purpose is to authenticate the request. And then that authentication can be used to provide proper authorization. Now that we’ve identified where the basic authentication occurs in the HTTP headers of the API request, let’s look a bit deeper at basic authentication. As I said, basic authentication includes a username and password in the HTTP headers. These credentials are encoded in Base64 format, but not encrypted. That’s an important distinction. Base64 is an encoding scheme, which is simply a way of representing data. And unlike encryption, it is not secure and can be easily decoded. So, although I’ve been referring to HTTP, you really should be using HTTPS with your REST APIs for security. HTTPS is HTTP plus TLS, Transport Layer Security, which provides robust encryption and security. The username and password used for basic authentication are sent in the format username colon password, encoded in Base64. For example, username jeremy and password ccna would be sent as this string of characters. If you’re curious, you can visit this URL, base64decode.org, to encode and decode base64. So, let’s see how basic authentication works in action. On the right here we have the REST server, with an API allowing access to its data. And on the left we have a client app that wants to access the data. It sends an API call, including the “Authorization” header for authentication. Notice the password is encoded in Base64; that’s username jeremy and password ccna. The authentication succeeds, so the server grants the request and responds with the data. So, it’s that simple: a username and password are included with each request, and if they’re correct, authentication succeeds. Now that we’ve seen how basic authentication works, let’s consider the advantages and disadvantages. Honestly, the main advantage is that it’s simple and easy to implement, just a username and password. But since those credentials are sent in every request, attackers could steal them if the connection isn’t properly secured. But really, that applies for any authentication method: HTTPS is essential when communicating over the modern Internet; you shouldn’t use regular HTTP. But even if using HTTPS for encryption, relying solely on a username and password combination isn’t particularly secure. If an attacker gets access to the credentials, whether through social engineering or another attack, they get access to the API. So that’s basic authentication. Let’s move on to the next method. Next, we’ll look at bearer authentication, which is a form of token-based authentication, and uses a token instead of a username and password. In bearer authentication, the client first obtains a token by authenticating with an authorization server, often just called an “auth server”. This is typically different from the server actually hosting the resource the client wants to access. Note that authenticating with the auth server can be done using basic authentication or another authentication method. This step is separate from the actual API request to the resource server. Then, after the client gets the token, for each API request, the client includes the token in the HTTP authorization header like we saw before. For example, it will look something like this: Authorization: Bearer, and then the token. Let’s see how it works. Notice I’m showing two servers now. One is the auth server, which generates the token. And then the resource server, which hosts whatever resource the client wants to access. So, to begin, the client requests a token from the auth server, and if successful, the server grants the client a token. Then, when the client sends an API call to the resource server, it includes the token in the call. And then the resource server responds, either with the requested resource, or a message indicating the server did what was requested. So, that’s basically how bearer authentication works. The term “bearer” means that anyone who possesses the token can use it. This means that, if an attacker steals the token, they can make requests, API calls, as if they were the legitimate user. This is clearly a security problem, so to mitigate against this, tokens usually expire after a set period of time. The expiration time depends on the API’s security needs. Some tokens expire in 15 minutes to reduce risk, while others last weeks or months for convenience, especially in low-security environments. Okay, let’s summarize by considering some advantages and disadvantages of bearer authentication. First off, it’s more secure than basic authentication, because there’s no need to transmit the same username and password for every single API call. The tokens that are used instead expire, so a stolen token will only be temporarily valid. But still, it’s worth mentioning as a disadvantage that, if the token is stolen, the attacker can still access the API until the token expires. And since tokens need to be refreshed periodically, it adds some extra complexity when implementing bearer authentication, compared to basic authentication. That’s not a problem for network engineers, but for the programmers who build these APIs it’s worth considering. And finally, just like basic authentication, it should only be used with HTTPS. If the token is sent in cleartext, no encryption, it simply isn’t secure; you need HTTPS when communicating over the modern internet. While bearer tokens are commonly used for user authentication in APIs, some APIs use a simpler method, which we’ll cover next. Next up is API key authentication, which uses a static key issued by the API provider. The client uses this key in each API call for authentication. The main difference between a bearer token and a key is that, unlike bearer tokens, the API key is static. It doesn’t expire automatically, so it remains valid until revoked. API keys can be sent to the server in a few ways. The recommended way is to include the key in the HTTP Authorization header, as we saw in basic and bearer authentication. But you can also include the key in the URL, in the start line of the HTTP request, by adding a parameter to the URL. But this is not recommended for several reasons, one being that since URLs are often logged by web servers, proxies, and browsers, API keys included in URLs can be exposed in logs, making them vulnerable to attackers. And a third option is to send the API key as a cookie, which is sometimes used for browser-based APIs. But in any case, the recommended method is to include the key in the authorization header. Let’s see what it looks like; it’s quite simple. The client sends an API call to the server hosting the resource it wants to access. And the client includes the API key in the authorization header of the HTTP message. Assuming the key was valid, the server then sends its response. Okay, now that we’ve seen how it works, let’s consider a couple of advantages and disadvantages. One advantage is that it’s easier to implement than Bearer authentication. And API key authentication is good for tracking usage. The API provider can assign a unique key to each customer, and then easily track each customer’s usage by tracking the key used in each API call. Because of this, API keys are often used in cloud services and third-party APIs. If you’re wondering what a third-party API is, think of a developer that builds a chatbot app that uses ChatGPT. The end users are the first party. The developer creating the chatbot app is the second party. But instead of generating responses itself, the app calls OpenAI’s API to get responses from ChatGPT. Since OpenAI is external to both the users and the app developer, it’s the third party in this interaction. Hopefully that makes sense! Now let’s look at a couple of disadvantages. One problem is that, if stolen, the key grants full access until revoked. It doesn’t automatically expire. So, API keys must be rotated manually to maintain security, whereas the tokens used in bearer authentication expire automatically. Okay that’s all for API key authentication. Finally, we move on to OAuth 2.0. It’s a secure authentication framework that is widely used in modern web applications. Its overall purpose is different from the other methods we’ve looked at, in that it provides access delegation, granting third-party applications limited access to resources on behalf of the resource’s owner. The main benefit is that there is no need to share the resource owner’s credentials with the third party. For example, when you use ‘Log in with Google’ on a website, the website never sees your Google password. Instead, Google confirms your identity and grants access only to approved information. Let’s look at some examples of OAuth2.0. The first is what I just mentioned, logging in with google. Many websites and apps offer the option to log in using your Google account. The third party website or app is granted access to some of your Google account’s information, without actually getting access to your account’s credentials. Connecting apps to social media accounts is another example. Many apps can be connected to Instagram, Facebook, LinkedIn, etc. OAuth 2.0 lets these apps access your social media account for specific tasks, like posting on your behalf, without revealing your login credentials. Calendar integration is one more example. A third-party tool, like a scheduling app, can be given access to your Google calendar to check availability and schedule meetings. These are all common examples of OAuth2.0. Now let’s see how it actually works. There are four main parties involved. First is the resource owner, the account owner granting access to their data. Using the Google calendar integration example, this is the owner of the google account. Next is the client app, the third-party application requesting access to your Google data, like a scheduling tool accessing your calendar. Then there is the auth server. This server issues access tokens, granting limited access to your google account, after receiving user approval. In this example, this is Google’s OAuth service. Finally, there is the resource server, the server that hosts the protected resource. In this example, it’s the server hosting the Google calendar data that the client app wants to access. Now let’s see OAuth2.0 in action. The overall process consists of six main steps. First, the client app requests authorization from the resource owner. In our example, this could be a scheduling app requesting access to your Google Calendar. Next, the resource owner—which is you, the account owner—grants authorization by logging into your Google account and giving permission for the scheduling app to access your calendar data. Once permission is granted, the client app exchanges this authorization grant for an access token from the auth server—which in this case, is Google’s OAuth service. The auth server then issues an access token to the client app. This token acts as a temporary key that allows the app to request resources on your behalf. Now that the client app has a token, it includes the token in an API request to the resource server, which hosts the actual data—in this case, your Google Calendar data. Finally, the resource server validates the access token and provides the requested resource back to the client app. If the token is valid and the app has the correct permissions, it will receive the data it needs. The key part of OAuth 2.0 is the access token issued in step 4. It functions like the tokens we saw in bearer authentication. It grants access to the specified resource within the allowed scope, for example read-only access. And just as in bearer authentication, access tokens expire after a short period, which helps improve security. But instead of requiring the user to log in again every single time the access token expires, OAuth 2.0 uses refresh tokens, granted by the auth server, which allow the client app to request a new access token without user interaction. This way, the app can maintain access over an extended period of time without constantly requiring the user to log in. So, that’s OAuth 2.0. It allows third-party apps to securely access a user’s data without exposing their credentials, and while allowing users to control what information is shared. That’s why OAuth 2.0 is so widely used in modern web applications. By the way, OAuth 2.0 is defined in RFC 6749, which you can access from this link here, or just google search for RFC 6749. Diving into RFCs isn’t expected for the CCNA exam, but if you’re curious to learn more about OAuth 2.0, it’s worth checking out. Alright, let’s wrap things up with a quick summary of what we covered in this video before we move on to the quiz. REST API authentication ensures that only authorized users or systems can access an API. Without it, anyone could send API requests, potentially exposing or modifying sensitive data. We looked at four types of REST API authentication methods. Basic Authentication uses a username and password encoded in Base64, but it’s not encrypted, so it must be used with HTTPS for security. Actually, that statement really applies to all of these authentication methods: in the modern internet, you should always use HTTPS, not regular HTTP. Bearer Authentication is a step up in security, using a token issued by an authorization server instead of sending a username and password in every request. Tokens expire after a short time, which increases security, but they can still be stolen if not protected with HTTPS. Next, API Key Authentication works similarly but uses a static key issued by the API provider. It’s good for tracking API usage, so it’s commonly used by cloud service providers and third-party APIs. It’s easier to implement than bearer authentication, but it’s considered less secure because stolen keys remain valid until manually revoked. They don’t automatically expire. Finally, OAuth 2.0 is a framework for access delegation, allowing third-party applications limited access to a user’s resources without sharing login credentials. It relies on access tokens that can be refreshed with a refresh token, allowing continued access without user reauthentication. OAuth 2.0 involves four key parties: the resource owner, for example, the owner of the Google account. The client app, the app that requests access to the account’s resources. The authorization server, which grants the client app a token to provide limited access to the requested resource. And finally, the resource server; the server that hosts the protected resource: for example, the Google account’s information. Okay, that’s what we covered in the video. Now let’s move on to a quick quiz to test your understanding. Here’s quiz question 1. Which of the following REST authentication methods involve an Auth server issuing tokens? Select two. Pause the video now to think about your answers. Okay, the answers are A and B, OAuth 2.0 and bearer authentication. Here’s the diagram I showed for OAuth 2.0, and here’s the diagram for bearer authentication. Basic authentication doesn’t involve an auth server; it just uses simple username and password authentication. And neither does API key authentication, which uses a static key. Okay, let’s go to the next question. Here’s question 2. Which of the following best describes how OAuth 2.0 improves security? Pause the video now to think about your answer. Okay, the answer is B, it allows third-party apps to access resources without exposing user credentials. Here’s the diagram once again. Instead of using the resource owner’s credentials for authentication, the client app receives an access token from the auth server in step 4, which allows it to authenticate with the resource server in step 5, and then access the resource. Okay, let’s go to the next question. Here’s question 3. Which of the following statements are true? Select three. Pause the video now to think about your answers. Okay, the answers are B, C, and E. B is correct because bearer authentication does require a token; the term “bearer” refers to this bearer token. C is correct because OAuth 2.0 enables access delegation, as we covered in the previous quiz question. And E is correct because, instead of requiring user reauthentication every time the access token expires, a refresh token can be used to automatically obtain a new access token. A is incorrect because API keys do not expire automatically; for this reason, they are considered less secure than tokens. D is incorrect because basic authentication doesn’t use encryption. Instead, the username and password are encoded in Base64 format, which is easily reversible. Finally, F is incorrect because API keys should not be included in URLs. Instead, they should be included in the HTTP Authorization header, as this is more secure. Okay, that’s all for the quiz. And that’s all for this video on REST API authentication. We covered four kinds: basic authentication, bearer authentication, API key authentication, and OAuth 2.0. There are other REST authentication methods out there, but these are the four I recommend knowing for the CCNA exam. I hope you found this video helpful. Thanks for watching.