# Cloud Application Identity and API Security

> Chapter 12 of the Courseiva ISC2-CCSP curriculum — https://courseiva.com/learn/isc2-ccsp/cloud-application-identity-and-api-security

**Official objective:** 4.3 — Apply secure software components, APIs, and identity management to cloud applications

## Introduction

How do you stop unauthorised users or malicious bots from accessing a cloud application's sensitive functions? This question is at the heart of cloud application identity and API security, because without strict controls, your cloud apps are vulnerable to data breaches, account takeover, and expensive resource abuse. For the CCSP exam, you must understand how to secure the components that let applications talk to each other (APIs) and verify who is making the request (identity).

## The Secure Parcel Delivery Analogy

When you order a parcel online and want it delivered securely to your home, the courier needs to confirm that you are the right recipient. First, you place the order with a specific address and your unique identifier (like a customer number), which leads to the courier system generating a one-time delivery code. This code is like an API key – a secret token that proves you are authorised to receive that specific package. 

 The delivery driver arrives and asks for the code. You provide it, and the driver checks it against their manifest. This check is exactly how an API validates a request: it looks at the token, verifies it hasn't expired, and confirms it matches the right resource (your parcel). But what if a stranger claims to be you? That's why the driver also checks your ID – this is identity management, like multi-factor authentication (MFA). 

 Without this process, anyone could steal your parcel. In the cloud, without proper identity and API security, an attacker could steal data or invoke expensive services. The courier company also logs every delivery attempt – a perfect analogy for cloud logging and monitoring. The entire system only works if everyone trusts the process: the website, the driver, and the recipient. This maps precisely to how cloud applications use API security (the delivery code), identity management (your ID check), and secure components (the locked truck) to protect data.

## Core explanation

To understand cloud application identity and API security, you first need to know what an API is. API stands for Application Programming Interface. Think of it as a waiter in a restaurant. You (the user or application) tell the waiter what you want (the request), the waiter goes to the kitchen (the server or cloud service), and brings back your food (the response). Without the waiter, you cannot order. Without an API, applications cannot request data or services from each other. 

 Now, why does identity matter here? Every time you talk to that waiter, they need to know who you are and what you are allowed to order. Identity management is the system that handles this. It involves verifying a user or application's identity (authentication) and then deciding what that identity is allowed to do (authorisation). In the cloud, this is managed by a central service like Microsoft Entra ID (formerly Azure AD) or AWS Identity and Access Management (IAM). 

 An API security strategy ensures that only authenticated and authorised requests are processed. Without it, anyone could send a request to delete a database or access customer records. API security typically uses tokens (like JSON Web Tokens or JWTs) to prove identity. When an application makes an API call, it sends a JWT that contains information about who they are and what permissions they have. The API then validates this token using a secret key or a public key, ensuring it hasn't been tampered with and hasn't expired. 

 This system replaces old methods like static passwords or IP whitelisting, which were easy to bypass. For example, a static password embedded in code could be leaked, whereas a token can be expired after a short time. Additionally, API security includes rate limiting (preventing too many requests in a short time), encryption (using HTTPS to protect data in transit), and logging every API call for audit purposes. 

 Why does this exist? Cloud applications are distributed. Your frontend might run on a server in London, while the database runs in Singapore. They need to communicate over the internet securely. Identity and API security create a trusted channel between these components. 

 For the CCSP, you must also understand the principle of least privilege. This means an identity (user or service) should only have the minimum permissions needed to perform its job. For example, a reporting application should only be allowed to read data, not delete it. This reduces the damage if an attacker compromises that application. 

 Finally, consider OpenID Connect (OIDC) and OAuth 2.0. OAuth 2.0 is an authorisation framework that lets applications get limited access to user accounts without exposing passwords. OpenID Connect sits on top of OAuth 2.0 and adds identity verification (like checking a user's name and email). These are the industry standards you will see heavily in the exam. 

 In summary: API security secures the communication channel; identity management secures who or what is on that channel. Together, they form the backbone of secure cloud application design.

## Real-world context

Imagine you work as a cloud security engineer for a company that runs a healthcare application. Patients book appointments through a mobile app, and doctors access patient records via a web portal. Both systems communicate with a central API that queries a database. Your job is to secure this entire flow. 

 Here is what happens step by step in a typical day: 

 - First, you configure identity management using Microsoft Entra ID. You create user accounts for each doctor and patient, assigning roles such as 'doctor' or 'patient'. Each role has different permissions – doctors can view and edit medical records, patients can only see their own appointments. 

 - Next, you set up API security. Every time the mobile app wants to fetch the list of available appointments, it sends an API request with a JWT token. This token is generated after the patient logs in successfully with their username and a one-time passcode (two-factor authentication). The API validates the token, checks that it hasn't expired, and then returns only the data relevant to that patient. 

 - You also implement rate limiting. Without it, a malicious user could spam the API with thousands of requests, causing the system to slow down or crash for everyone else. You configure the API gateway to allow a maximum of 100 requests per minute per user. 

 - Additionally, you enable logging for every API call. If a security incident occurs (like an unauthorised access attempt), you can review the logs in a tool like AWS CloudTrail or Azure Monitor. This helps you trace which identity made the request, what resource was accessed, and from which IP address. 

 - Finally, you regularly rotate the API keys used for server-to-server communication. For instance, the appointment booking service needs to talk to the payment service. They share a long-term secret key, but you set a policy to rotate it every 90 days. If a key is compromised, the damage is limited because the old key stops working. 

 What you actually do daily: review access review reports, update IAM policies, patch API endpoints against known vulnerabilities (like injection attacks), and test your rate limiting rules. You also collaborate with developers to ensure they follow secure coding practices, such as never hardcoding secrets in the application code. This scenario mirrors what the CCSP expects you to manage in a professional context.

## Exam focus

The CCSP exam heavily tests your understanding of cloud application identity and API security, particularly within domain 4 (Application Security). You must know specific concepts cold, because the exam loves to trick you with similar-sounding terms. 

 Here are the exact topics and trap patterns you will face: 

 - OAuth 2.0 vs OpenID Connect (OIDC): The exam will present a scenario where an application needs to know who a user is (identity) versus just what they can access (authorisation). The trap: they give you a scenario about 'authorising access to an API' and you might think OpenID Connect, but the correct answer is OAuth 2.0 because it handles delegation of access. OIDC is for authentication (proving identity). Memorise: OAuth 2.0 = authorisation, OIDC = authentication + identity. 

 - Federation vs Single Sign-On (SSO): The exam may ask which technology allows a user to log in once and access multiple cloud services. SSO is the result; federation is the underlying technology that uses trust relationships between identity providers (like Microsoft Entra ID and Google Workspace). A common trap: they ask 'what allows users to use their corporate credentials in a cloud app?' Answer: federation, not just SSO. 

 - API Keys vs Tokens: API keys are long-lived static secrets (like a password for an app). Tokens (like JWTs) are short-lived and contain metadata. The exam will test which is more secure in a given scenario. The correct answer is usually tokens because they expire and can be revoked. 

 - Principle of Least Privilege (PoLP): This appears in every exam domain. They give a scenario where a developer gives an application 'full access' to a database. The correct answer is to limit it to read-only. Always look for the option that restricts permissions to only what is needed. 

 - Mistaking Identity Provider (IdP) for Service Provider (SP): The exam often describes a cloud service that stores user data (the service provider) and a separate system that verifies the user (the identity provider). A common trap is confusing which component issues the token. Remember: the IdP issues the authentication token; the SP consumes it to grant access. 

 Key definitions to memorise: 

 - JWT (JSON Web Token): A compact, self-contained way to transmit information between parties as a JSON object. Used for API authentication. 

 - SAML (Security Assertion Markup Language): An XML-based standard for exchanging authentication and authorisation data between an IdP and a SP. 

 - OAuth 2.0: A protocol that allows a user to grant a third-party application limited access to their resources without sharing their password. 

 - OpenID Connect: An identity layer on top of OAuth 2.0 that verifies the end user's identity. 

 Trap pattern: The exam might describe a scenario where you need to 'secure an API that is publicly exposed'. The answer will not be 'use a firewall' (though that helps) but rather 'implement OAuth 2.0 with token validation'. Another trap: they ask about 'identity management for cloud applications' and offer 'encryption at rest' as a distractor. Encryption protects data, but identity management controls access. Stay focused on access control. 

 Finally, the exam expects you to understand that API gateways (like AWS API Gateway or Azure API Management) are central tools. They handle rate limiting, token validation, and logging. You will see questions where the correct answer involves configuring the API gateway to enforce security policies.

## Step by step

1. **Define the Identity Sources** — First, identify all the identities that will interact with the cloud application: human users (employees, customers), service accounts (applications), and external systems. Map each to a directory service like Microsoft Entra ID or AWS IAM.
2. **Select an Authentication Protocol** — Choose an industry-standard protocol like OAuth 2.0 combined with OpenID Connect for token-based authentication. This allows you to issue short-lived JWTs that the API can validate without calling the identity provider every time.
3. **Configure the API Gateway** — The API gateway sits in front of your backend APIs. Configure it to validate every incoming request for a valid JWT token, enforce rate limits (e.g., 100 requests per minute), and log all requests for audit trails.
4. **Assign Permissions Using IAM Roles** — Use IAM roles (not individual user credentials) for applications. Assign roles with precise permissions, such as read-only or write-only, following the principle of least privilege. Never use long-term access keys in source code.
5. **Implement Monitoring and Rotation** — Set up alerts for suspicious API usage (e.g., multiple failed token verifications). Rotate API keys and service account credentials on a schedule (e.g., every 90 days). Expire tokens after a short time (e.g., 15 minutes) to limit exposure if stolen.

## Comparisons

### OAuth 2.0 vs OpenID Connect (OIDC)

**OAuth 2.0:**
- Purpose: authorisation to access resources
- Token type: access token only
- Does not verify end-user identity

**OpenID Connect (OIDC):**
- Purpose: authentication and identity verification
- Token type: ID token (plus access token)
- Verifies end-user identity and provides profile info

### API Key vs JWT Token

**API Key:**
- Long-lived static string
- Usually passed in HTTP header
- Difficult to revoke without changing key

**JWT Token:**
- Short-lived (often minutes to hours)
- Self-contained with claims and signature
- Easily revocable by expiring token or blacklisting

### IAM Role vs IAM User

**IAM Role:**
- Designed for applications and services
- Temporary credentials via STS
- Automatically rotated permissions

**IAM User:**
- Designed for human users
- Long-term credentials (password or access key)
- Requires manual rotation or user action

### Microsoft Entra ID (Cloud Identity) vs On-Premises Active Directory

**Microsoft Entra ID (Cloud Identity):**
- SaaS-based, no physical servers to manage
- Supports modern protocols (OAuth, SAML)
- Built for internet-scale and mobile devices

**On-Premises Active Directory:**
- Installed on local server infrastructure
- Primarily uses Kerberos and LDAP
- Designed for local network domain control

## Diagram

_This diagram shows how a user authenticates via an identity provider, receives a JWT token, and the API gateway validates that token before allowing access to the Cloud API and database._

```mermaid
graph LR
    A[User] -->|Login + MFA| B[Identity Provider]
    B -->|Issues JWT Token| C[API Gateway]
    C -->|Validates Token| D[Cloud API]
    D -->|Authorise Request| E[Database]
    F[Admin] -->|Configures| C
    C -->|Logs Requests| G[Cloud Logging]
    H[Attacker] -->|Bad Token| C
    C -->|Rejects| H
```

## Common misconceptions

- **Misconception:** API security is just about using HTTPS (encryption). **Reality:** HTTPS only protects data in transit. API security includes authentication, authorisation, rate limiting, input validation, and logging. Encryption is just one layer. (Beginners often think encryption alone makes an API secure, forgetting that the API itself might be vulnerable to attacks like injection or unauthorised access.)
- **Misconception:** If an application uses an API key, it is automatically secure. **Reality:** API keys are static and can be leaked. They should be treated like passwords and rotated regularly. They are a basic form of identification, not authentication, and lack mechanisms for granular permissions or revocation. (Many people assume a key is enough because it seems like a 'secret'. They don't realise that an exposed key gives full access until it is manually revoked.)
- **Misconception:** Cloud identity management is the same as on-premises Active Directory. **Reality:** On-premises AD is a directory service for managing users and computers in a local network. Cloud identity management (e.g., Microsoft Entra ID) is designed for internet-scale, supports federation, and integrates with SaaS applications via protocols like OAuth and SAML. (Because both are from Microsoft and both manage users, beginners conflate them. They miss that cloud identity is identity-as-a-service with different capabilities.)
- **Misconception:** OAuth 2.0 and OpenID Connect are interchangeable terms. **Reality:** OAuth 2.0 is for authorisation (granting access to resources). OpenID Connect is an authentication layer on top of OAuth 2.0 that verifies who the user is. They are related but serve different purposes. (Both involve tokens and sign-in flows, so beginners use them incorrectly. The CCSP exam specifically tests this distinction.)
- **Misconception:** A service account and a user account are managed the same way. **Reality:** Service accounts (non-human identities) should have minimal permissions, be rotated frequently, and often use tokens or keys instead of passwords. User accounts are for humans with multi-factor authentication and password policies. (Because both are 'identities', newcomers treat them identically, ignoring that service accounts can be exploited if given excessive privileges.)

## Key takeaways

- API security requires a combination of encryption, authentication, authorisation, rate limiting, and logging, not just HTTPS.
- OAuth 2.0 is an authorisation protocol; OpenID Connect adds identity verification on top for authentication.
- The principle of least privilege dictates that an identity should only have the minimum permissions necessary to perform its function.
- API keys are long-lived static secrets that should be rotated regularly and are not a substitute for strong authentication like tokens.
- Federation allows users from one organisation to use their existing credentials to access cloud applications in another organisation.
- An API gateway centralises security controls like token validation, rate limiting, and logging for all API traffic.
- JSON Web Tokens (JWTs) are self-contained tokens that carry claims about the user and are signed to prevent tampering.
- Service accounts and user accounts have different security requirements; service accounts must be protected with least privilege and key rotation.

## FAQ

**What is the difference between authentication and authorisation?**

Authentication verifies who you are (e.g., logging in with a password). Authorisation determines what you are allowed to do (e.g., viewing only your own files). Both are required for API security.

**What is a JWT and why is it used for APIs?**

A JWT (JSON Web Token) is a compact, self-contained token that carries user information and permissions. It is used for APIs because the API can validate the token without contacting a central server, making authentication fast and stateless.

**Do I need to use both OAuth 2.0 and OpenID Connect together?**

Typically yes if you need to know who the user is. OAuth 2.0 alone only gives you a token to access resources. OpenID Connect adds an identity token that tells you who the user is. For APIs that need user identity, use both.

**What happens if an API key is leaked?**

Anyone with that key can make requests as the authorised application, potentially accessing or modifying data. You must immediately revoke the key and issue a new one. This is why short-lived tokens are safer than long-lived keys.

**What is an API gateway and why do I need one?**

An API gateway is a centralised service that sits between clients and backend APIs. It handles security tasks like token validation, rate limiting, and logging, reducing the burden on individual APIs and ensuring consistent policy enforcement.

**How does federation work for cloud applications?**

Federation establishes a trust relationship between an identity provider (e.g., Microsoft Entra ID) and a service provider (e.g., Salesforce). Users log in once at their organisation's IdP, and the IdP issues a token that the service provider accepts, enabling single sign-on.

## Check your understanding

1. **Which protocol is used to authorise a third-party application to access a user's Google Drive files without sharing the password?**

   Answer: OAuth 2.0. It allows delegated access through an access token.

2. **What is the primary advantage of using a JWT token over a static API key?**

   Answer: A JWT token is short-lived and self-contained, reducing the window of exposure if stolen, and it includes claims that can be validated without contacting the identity provider.

3. **What does an API gateway do in the context of security?**

   Answer: It centralises security controls including token validation, rate limiting, IP filtering, and request logging before forwarding traffic to backend APIs.

4. **If an application only needs to read data from a cloud database, what IAM permission principle should you apply?**

   Answer: The principle of least privilege – you should grant read-only access, not full read-write or admin permissions.

5. **What is the role of an identity provider in a federated login scenario?**

   Answer: The identity provider authenticates the user and issues a token that the service provider accepts, enabling single sign-on across multiple applications.

---

Interactive version with quiz and diagrams: https://courseiva.com/learn/isc2-ccsp/cloud-application-identity-and-api-security