API Authentication: API Keys, Basic Auth, and OAuth2

An API is an Application Programming Interface — it is a set of rules that lets one piece of software talk to another. For example, when your weather app asks a remote server for today's forecast, it does so through an API. But the server needs to know who is asking and whether they are allowed to get the data. That is what authentication does: it proves your identity to the API.

Let us start with the simplest method: API Keys. An API key is a long, unique string of characters that the API provider gives to you, the developer. Think of it like a password that is shared between two machines. When your app makes a request to the API, it includes this key, often in the URL or in a special part of the request called a header. The server checks the key against its database. If it matches, the request is allowed. API keys are easy to implement and fast, but they have drawbacks. Because the key is the only thing used for identification, if it is exposed — say, you accidentally upload it to a public code repository like GitHub — anyone can use it. API keys are also usually static: they do not expire unless you manually rotate them. This means a compromised key stays compromised until someone changes it.

Next is Basic Authentication, often called Basic Auth. In this method, your app sends a username and password with every single API request. But it does not send them as plain text. Instead, it combines them into a single string in the format "username:password" and then converts that string using a method called Base64 encoding. For example, if your username is "alice" and your password is "secret123", the combined string "alice:secret123" becomes "YWxpY2U6c2VjcmV0MTIz". This encoding is NOT encryption — it is just a way to represent binary data in text. Anyone who intercepts that encoded string can decode it instantly with any Base64 decoder tool. The real world uses Basic Auth only over HTTPS, because HTTPS encrypts the entire communication channel, protecting the encoded credentials during transit. Even so, Basic Auth is considered weak for modern applications because the credentials are sent on every request, increasing exposure risk. The server must also store the passwords (ideally as hashes), which creates a management burden.

The most sophisticated method is OAuth 2.0 (Open Authorisation 2.0). OAuth 2.0 is not a single technique but a framework — a set of rules that allows one service to grant limited access to another service on behalf of a user, without the user revealing their password directly. It is the system behind "Sign in with Google" or "Sign in with Facebook." Let us break down its key components. First, there is the Resource Owner — usually the end user who owns the data. Second, the Client — the application that wants access to that data. Third, the Authorisation Server — the service that issues tokens after authenticating the user. Fourth, the Resource Server — the API that holds the actual data.

The flow works like this. The client application redirects the user to the authorisation server's login page. The user authenticates (logs in) and then is shown a consent screen that says, "This app wants to access your contacts. Allow or deny?" If the user approves, the authorisation server issues an authorisation grant to the client. The client then exchanges that grant for an access token — a temporary, opaque string that acts as a key to the resource server. The client includes this access token in every API request to the resource server, which validates the token without ever seeing the user's password. The access token typically expires after a short time (e.g., sixty minutes), and the client may also receive a refresh token that allows it to get new access tokens without bothering the user again. This design limits the damage if a token is stolen — the token expires, and the user can revoke it from the authorisation server.

The OAuth 2.0 framework defines several grant types (flows) for different scenarios. The Authorisation Code flow is the most secure for web apps. The Implicit flow is simpler but less secure, used for client-side apps like JavaScript in a browser. The Client Credentials flow is for server-to-server communication where there is no user involved — the client itself is the resource owner. The Resource Owner Password Credentials flow uses a username and password directly (like Basic Auth but within the OAuth framework) and is generally discouraged.

Why does this matter for the 200-901 exam? Cisco APIs, such as those for managing Meraki or Webex, use these methods. You will need to know when to use each, the security trade-offs, and how to implement them in simple REST API calls. API keys are common for low-risk public endpoints. Basic Auth is sometimes used in legacy systems or quick prototypes. OAuth 2.0 is the modern standard for any application that handles user data or requires fine-grained permissions.

Imagine you work as a network administrator at a medium-sized company that uses Cisco Meraki for wireless networking and Webex for team collaboration. Your manager asks you to write a script that automatically pulls usage data from the Meraki dashboard and posts a daily summary to a Webex team room. This is a perfect scenario to understand these authentication methods in practice.

First, you need to access the Meraki API. You log in to the Meraki dashboard, navigate to the API access section, and generate an API key — a long string like '6b4b7f1a2c3d4e5f6a7b8c9d0e1f2abc'. You copy this key carefully and store it in a secure environment variable, never in the script's code. Your script then sends a GET request to the Meraki API endpoint, including this key in the request header as X-Cisco-Meraki-API-Key: your-key-here. The Meraki server checks the key and returns the usage data in JSON format. This works well because the script is simply pulling data that your organisation owns — there is no user-specific data involved. The key grants broad access, so you must guard it fiercely.

Next, you need to post the summary to a Webex team room. Webex uses OAuth 2.0 because you are asking Webex to act on behalf of a user (you) to post messages. You cannot simply use an API key because Webex needs to know who is posting and ensure they have permission. Here is the step-by-step process you follow:

In this real scenario, you used both API keys (for Meraki) and OAuth 2.0 (for Webex) in the same project. You never used Basic Auth because it is too risky for a production script that runs unattended — if the username and password were ever exposed, an attacker could control everything. The OAuth 2.0 flow gave you granular control: the script only had permission to post messages, not to read private files or delete rooms. If you needed to revoke the script's access later, you could revoke the OAuth grant from the Webex portal without changing any user passwords. This is the practical value of these authentication methods: they balance security, convenience, and control in a way that matches the needs of the task.