Threat Modeling for OAuth 2.0 Authorization Framework

In this blog, we will see the basics of Threat Modeling, including its key components, boundaries, and an introduction to OAuth. As the default template in the Microsoft Threat Modeling Tool doesn’t include all entities as per our need. We’ll see a practical demonstration to create a custom template which suits our specific needs. Later on, we’ll explore the design approach for creating a threat model diagram for OAuth 2.0 Authorization Framework using the Microsoft Threat Modeling Tool.

Threat modeling is like putting on a detective hat and looking at a system from a bad guy’s point of view. You’re trying to figure out all the different ways someone could mess with it or cause problems. In other words Threat modeling is a structured approach used to identify and analyze potential threats and vulnerabilities in a system or application.

Why threat modeling is still required even if penetration testing is performed?

While penetration testing is an essential component of a comprehensive security strategy, threat modeling provides additional benefits by identifying and addressing security concerns early in the software development process, ultimately leading to more secure and resilient software systems.

Proactive vs. Reactive Approach: Threat modeling takes a proactive approach by identifying potential security threats and vulnerabilities early in the software development process, before any code is written. Testing, on the other hand, takes a reactive approach by identifying vulnerabilities after the software has been developed. By incorporating threat modeling before development begins, teams can prevent security issues from being introduced in the first place, saving time and resources that would otherwise be spent on fixing vulnerabilities later.Systematic Identification of Threats: Threat modeling provides a structured methodology for systematically identifying and analyzing potential security threats and vulnerabilities based on the system’s architecture, design, and functionality. This helps in understanding the security posture of the system as a whole and prioritizing security concerns based on their severity and likelihood of occurrence.Comprehensive Coverage: While testing is essential for validating the security of a software system, it may not always cover all possible attack scenarios or identify all potential security issues. Threat modeling helps in identifying security concerns that may not be easily detectable through testing alone, such as design flaws, misconfigurations, or business logic vulnerabilities.Risk Management: Threat modeling enables teams to assess and manage security risks proactively by developing mitigation strategies and countermeasures to address identified threats and vulnerabilities. This helps in prioritizing security efforts and allocating resources effectively to mitigate the most critical risks.Cost and Time Savings: Addressing security issues early in the development process through threat modeling can help in avoiding costly rework and delays that may occur if vulnerabilities are discovered later during testing or post-deployment. Investing in security upfront through threat modeling can ultimately save time and resources in the long run.

Let’s start Threat modeling: Initially, identify the assets or components of the system which you’re trying to protect, whether it’s a website, an app or a network. Then, you think about how a attacker mess with it and why.

Next step, is to identify weak points or vulnerabilities within the system. These vulnerabilities can include issues like weak passwords, outdated software, or insecure communication channels. Other common vulnerabilities involve Insufficient access controls, injection vulnerabilities, and insufficient logging and monitoring or places where someone could infiltrate without being noticed.

Once you’ve identified the threats, you come up with ways to defend against them. This could involve adding security measures like encryption, firewalls, or regular software updates.

Overall, threat modeling helps you understand the risks to the system and come up with a plan to keep it safe from all the bad stuff out there.

Threat modeling typically involves several key components:

Identify Assets: This step involves identifying what you want to protect. It could be data, systems, software, hardware.

Create a Diagram: Visualizing the system or application helps in understanding how different components interact and where vulnerabilities might exist. This could be a network diagram, data flow diagram. we will use Microsoft Threat Modeling Tool here.

Identify Threats: Think like a attacker and identify all the ways someone could exploit vulnerabilities in the system. This includes both intentional threats (like hackers) and accidental threats (like system failures).

Determine Vulnerabilities: Analyze each component of your system to identify vulnerabilities that could be exploited by threats. This could include things like outdated software, weak passwords, or insecure communication channels.

Assign Risk Levels: Not all threats are created equal. Assess the potential impact and likelihood of each threat and prioritize them based on the level of risk they pose to your assets.

Mitigation Strategies: Develop strategies to address the identified threats and vulnerabilities. This could involve implementing security controls, such as encryption, access controls, or regular software updates, to reduce the risk of exploitation.

Review and Update: Threat modeling is an ongoing process. Regularly review and update threat model as system evolves or new threats emerge.

Let’s talk about boundaries In threat modeling, they are like imaginary lines that delineate different areas of a system based on trust levels. These boundaries help in understanding where potential vulnerabilities might lie within the system.

There are various types of boundaries commonly considered in threat modeling:

Trust Boundary: This boundary separates trusted parts of the system from untrusted parts. Inside the trust boundary are secure components, such as servers or databases, where sensitive data is stored. Outside the trust boundary are areas like the internet or user inputs, which are considered less trustworthy.

Data Boundary: This boundary separates different types of data based on their sensitivity levels. For example, it could separate public data from private or confidential data. Data boundaries help in identifying which data needs stronger protection measures.

Network Boundary: This boundary separates internal network segments from external ones. It helps in understanding how data flows within the network and where potential entry points for attackers might exist.

Perimeter Boundary: This boundary defines the perimeter of the system or organization. It includes all the entry and exit points, such as network gateways or physical access points, which need to be protected from unauthorized access.

Physical Boundary: This boundary separates the digital aspects of the system from the physical environment. It includes physical assets like buildings, servers, and hardware components, which also need to be secured against physical threats like theft or vandalism.

By identifying and understanding these different types of boundaries, threat modelers can better analyze the security posture of a system and implement appropriate security measures to protect against potential threats and vulnerabilities.

OAuth 2.0 offers a method for distributed applications to access resources from another application and share information securely. But, it’s important to note that OAuth itself isn’t a way to confirm who you are. it’s not an authentication protocol. Instead, it’s often used with SAML or OpenID authentication protocols, which handle authentication.

Typically, we receive the application architecture from the client. In our scenario, we will conduct a threat modeling assessment for the OAuth & OIDC Framework, which includes the following entities: Authorization Servers, Resource Server, Web-GUI, OpenID provider, End user, ID Requester, ID token, Info.

Now we will see the Design approach for creating a threat model diagram using the Microsoft Threat Modeling Tool.

Identify Assets: Begin by identifying the assets in system. In this case, the assets could include the Authorization Servers, Resource Server, Web-GUI, OpenID Provider, End User, ID Requester, ID Token, and Information being exchanged.

Identify Trust Boundaries: Determine the trust boundaries within system. In OAuth 2.0, trust boundaries exist between the various components involved in the authorization flow. For example, there is a trust boundary between the Authorization Server and the Resource Server, as well as between the End User and the Web-GUI.

Identify Data Flows: Next, identify the data flows between the different components. For OAuth 2.0 Authorization Code Flow, data flows include the exchange of authorization codes, access tokens, and ID tokens between the Authorization Server, Resource Server, End User, and Web-GUI.

Identify Threats: Once you have identified the assets, trust boundaries, and data flows, identify potential threats to each component and data flow. Threats to consider in OAuth 2.0 Authorization Code Flow.

Mitigation Strategies: Finally, identify mitigation strategies to address the identified threats. Mitigation strategies for OAuth 2.0 Authorization Code Flow.

Create the Threat Model Diagram: Using the Microsoft Threat Modeling Tool, create a diagram that represents the components, trust boundaries, data flows, and identified threats.

What if default template doesn’t include the entities which is present in our system architecture?

The Microsoft Threat Modeling Tool is a flexible tool, and we can customize it to suit as per the our specific needs. Since the default template in the Microsoft Threat Modeling Tool doesn’t include all the entities present in our system architecture, we’ll customize it to suit our specific needs.

If you choose the default template, you’ll notice that the Resource Server entities are missing. Therefore, we’ll develop a custom template that includes all the necessary entities for our architecture. For instance, we’ll create the Resource Server entities as an example.

To create a custom template, follow these steps:

Open the Microsoft Threat Modeling Tool.Click on “Open template” and select the default template.
(We’ll modify the default template to avoid starting from scratch when creating our custom template.)Once the default template got open, Click at Add derived Stencil.Now you can see there are several options like Name, Description, Behavior and constraints. we are going to take a look at every filed

In the context of creating a Resource Server component in the template, we don’t necessarily need to select something for all of these constraints. However, depending on our specific system architecture and security requirements, we may choose to specify certain constraints to further refine the threat model.

Custom Template Diagram To Add Resource Server Component

Now we will have closer look for each constraint.

1. Constrain Code Type to: This constraint could be useful if you want to specify the programming language or framework used to implement the Resource Server. For example, if the Resource Server is implemented in Java or .NET, you could specify that here. Constrain Code Type have two option: “managed” and “unmanaged,” you would choose based on whether the code for your Resource Server is managed by a runtime environment (like Java or .NET) or unmanaged (like C or C++).

2. Constrain Running As to: This constraint is relevant if you want to specify the user account or privilege level under which the Resource Server runs. For example, you might specify that the Resource Server runs as a dedicated service account with limited privileges.

It is having multiple options now we will have a closer look for each option on basis of following you can chouse your best fit.

Kernel: If Resource Server operates in kernel mode, it can access hardware directly with the highest privilege level.System: If Resource Server runs with system-level privileges, enabling elevated tasks on the system.Network Service: If Resource Server operates under the Network Service account, with limited privileges accessing network resources via computer account credentials.Local Service: If Resource Server runs under the Local Service account, with restricted privileges for non-network services.Administrator: If Resource Server operates with full administrative privileges, allowing unrestricted access to system resources.Standard User with Elevation: If Resource Server operates with standard user privileges, capable of elevating permissions when needed, following the principle of least privilege.Standard User without Elevation: If Resource Server operates with standard user privileges and cannot elevate permissions, minimizing security risks.Windows App Store: If Resource Server is deployed and runs within the Windows App Store environment, adhering to its security and sandboxing measures.

3. Constrain Isolation Level to: This constraint is useful for specifying the level of isolation or sandboxing applied to the Resource Server. For example, you might specify that the Resource Server runs in a containerized environment for enhanced isolation.

Constrain Isolation Level is having following option:

AppContainer: The Resource Server operates within an AppContainer, enhancing security by restricting access to system resources and limiting capabilities.Low Integrity Level: The Resource Server operates at a low integrity level, isolating it from higher-privileged processes to reduce security risks.Microsoft Office Isolated Conversion Environment: The Resource Server runs in a secure, isolated environment for document conversion tasks, preventing malicious documents from impacting the system.Sandbox: The Resource Server operates within a secure sandbox environment, containing potential security breaches and protecting the underlying system from harm.

4. Constrain Accepts Input From to: This constraint could be used to specify the sources from which the Resource Server accepts input. For example, if the Resource Server accepts input from specific APIs or endpoints, you could specify them here.

5. Constrain Implements or Uses an Authentication Mechanism to: This constraint is important for specifying the authentication mechanism used by the Resource Server to validate client requests. For OAuth 2.0, you might specify that the Resource Server implements token-based authentication.

6. Constrain Implements or Uses an Authorization Mechanism to: Similar to authentication, this constraint is important for specifying the authorization mechanism used by the Resource Server to control access to resources. For OAuth 2.0, you might specify that the Resource Server implements OAuth 2.0 authorization mechanisms.

7. Constrain Implements or Uses a Communication Protocol to: This constraint is useful for specifying the communication protocols used by the Resource Server to interact with clients. For example, you might specify that the Resource Server communicates over HTTPS.

8. Constrain Sanitizes Input to: If the Resource Server processes user input, this constraint could be used to specify any input sanitization mechanisms implemented to prevent injection attacks.

9. Constrain Sanitizes Output to: Similarly, if the Resource Server generates output that is sent to clients, this constraint could be used to specify any output sanitization mechanisms implemented to prevent injection attacks.

When creating a custom component like “Resource Server” in the Microsoft Threat Modeling Tool, you have another leverage to add property.

If you will click at Add Property you will see the “New Property Attribute” and “New Property Attribute Value” fields are used to define specific properties or attributes of the component. These attributes can provide additional information about the component that is relevant for threat modeling purposes.

Here’s how you can approach defining these attributes for the “Resource Server” component:

1. New Property Attribute: This field is where you define the name of the property or attribute.

For a Resource Server, some relevant attributes might include:
Location: Specifies where the Resource Server is hosted (e.g., on-premises, cloud-based).
Access Control: Describes how access to resources is controlled (e.g., role-based access control, attribute-based access control).
Authentication Mechanism: Specifies how the Resource Server authenticates clients (e.g., OAuth 2.0, JWT tokens).
Supported Protocols: Lists the communication protocols supported by the Resource Server (e.g., HTTPS, OAuth 2.0).
Data Sensitivity: Indicates the sensitivity level of the data handled by the Resource Server (e.g., public, confidential, sensitive).

2. New Property Attribute Value: In this field, you provide the value or description corresponding to the attribute defined in the previous step.

For example:
Location: Cloud-based (Azure), On-premises (Private Data Center).
Access Control: Role-Based Access Control (RBAC), Attribute-Based Access Control (ABAC).
Authentication Mechanism: OAuth 2.0 Authorization Code Flow, JSON Web Tokens (JWT).
Supported Protocols: HTTPS, OAuth 2.0, OpenID Connect.
Data Sensitivity: Public (non-sensitive), Confidential (sensitive but not critical), Highly Sensitive (critical).

Following diagram outlines the flow of data dashed lines mark areas where data might be changed or seen by unauthorized parties and highlighting security measures which needs to be taken, For ensuring the integrity and confidentiality of user data in OAuth 2.0 based applications.

Threat Modeling Diagram for OAuth 2.0 Authorization Framework

In the OAuth 2.0 Authorization Code Flow, data flows through various stages involving tokens, scope, authorization codes, and redirect URIs. The diagram illustrates the flow of data and identifies trust boundaries where security measures are crucial.

Tokens: OAuth utilizes different types of tokens like access tokens, refresh tokens, and authorization codes. These tokens have specific purposes and lifespans, and they are used to grant access to resources securely.
Scope: Scope defines the level of access granted to an application regarding user data. It limits an application’s access to specific resources or methods.
Authorization Code and Redirect URI: The authorization code serves as an intermediate step in the authorization process and is exchanged for access and refresh tokens. Redirect URIs play a crucial role in detecting malicious clients and preventing phishing attacks.

To ensure security:

Data integrity and origin authentication are maintained through digital signatures on assertions.Bearer tokens are securely communicated between endpoints to prevent unauthorized access.Short-lived authorization codes are exchanged for tokens over secure connections.The authorization process involves safe delivery of codes, immediate usage in secure communications, and secure storage of refresh tokens.

Following are security considerations related to OAuth 2.0:

Security Depends on Context: OAuth’s security depends on various factors like the type of client application. It provides guidelines for different types of clients: web applications, user-agent-based applications (like those using a web browser), and native applications (like mobile apps).
Client Authentication: The server verifies the identity of the client. Web applications use passwords for authentication, while native and user-agent-based apps use different methods. The server must be careful not to give away sensitive information to unverified clients.
Client Impersonation: Measures are taken to prevent one client from pretending to be another. The server ensures the client’s authenticity, involves the resource owner (the person granting access), and doesn’t automatically accept repeated authorization requests without verification.
Access Tokens: These are credentials used to access protected resources. They must be kept confidential and transmitted securely. It’s recommended for clients to request only the necessary level of access.
Refresh Tokens: Similar to access tokens, these should be kept confidential and validated securely. Measures like token rotation can help detect misuse.
Authorization Codes: Used to verify the resource owner’s identity. They must be transmitted securely and used only once. The server authenticates the client and ensures the code matches the client.
Security Measures for Various Attacks: The document outlines protections against various attacks like guessing credentials, phishing, cross-site request forgery, clickjacking, code injection, and open redirectors. Measures include using secure channels (TLS), validating input, and preventing unauthorized redirects.

- Jayesh Kunwal