Threat modeling for OAuth 2.0 via Security by Design approach using the Microsoft Threat Modeling tool [Part 1]
In this post I am trying to explain OpenID Connect and OAuth 2.0 Threat Model and Security Considerations and Best Practices check list.
The best way to learn a new technology is by implementing it, here we try to do threat modeling for OIDC and OAuth 2.0.
I can say Security starts with a threat model. Threat modeling creates an approach for an open discussion with others who can be outside the development team or part to be Security by Design assessment team. It can lead to new ideas and security improvements in the product. Threat modeling forces the design team to consider mitigations as the system is designed rather than after a system is deployed.
When we design a system, it is important to understand the potential threats to that system and require to add appropriate defenses. As part of the secure SDLC and threat modeling, It is important to design the system from the start, keep security in mind because understanding how an attacker might be able to compromise a system, then make sure appropriate mitigations are in place from the beginning.
I want to say, Threat modeling is a structured process that creates a discussion for the security by design assessment and helps to take security decisions in the system, as well as changes to the design that are made along the way that impact security.
Threat modeling adopts the perspective of malicious hackers to see how much damage they could do. When conducting threat modeling, Team needs to perform a thorough analysis of the software architecture, business context, and other artifacts (e.g., functional specifications, user documentation, RFC, High level document, Low level document, sequence and message flow diagram).
When threat modeling performed correctly, it can provide a clear line of security efforts across a software project. The threat modeling process helps teams, document knowable security threats to an application and make rational decisions about how to address them.
Overall, a well-documented threat model provides assurances that are useful in explaining and defending the security posture of an application or computer system. And when the development organization is serious about security, threat modeling is the most effective way to do
Finally, an outcome of threat modeling is to enable teams to consider other aspects of security, such as what security commitments you wish to provide to customers.
Let’s start with Threat modeling for OAuth 2.0 and OpenID Connect.
How can we Approach OpenID Connect and OAuth2.0 Threats?
OAuth framework was initially designed for authorization not for authentication. But as per need added an extra layer of authentication to make this framework fit for authentication use case as well. So to take care authentication use case, OpenID connect was introduced.
There are some primary activities that need to be performed when do threat modeling.
Threat modeling for OIDC and OAuth start by understanding the different entities of an OAuth along with the security-sensitive data elements managed by those entities and identifying the types of threat agents and actor that can perform malicious activity to an application.
The first step is to define the scope and depth. Once a reasonable scope is determined, it needs to be broken down in terms of individual components.
First, Let’s start by refreshing our memory with a few basic definitions:
Authorization Servers: This server entity issuing access tokens to the client after successfully authenticating the resource owner and obtaining authorization. The below data elements are stored or accessible on the authorization server:
- usernames and passwords
- client ids and secrets
- client-specific Access and Refresh tokens
Resource Server: This server entity hosting the protected resources, capable of accepting and responding to protect resource requests using access tokens. It is assumed that a resource server has no knowledge of refresh tokens, user passwords, or client secrets.
Client Application: An application, or application component making protected resource requests on behalf of the resource owner
OpenID Connect adds an additional token called an ID token.
OpenID provider: The authorization server that issues the ID token.
end user: Whose information is contained in the ID token
Relying party: The client application that requests the ID token.
ID token: It is issued by the OpenID Provider and contains information about the end user in the form of claims.
Claim: It is a piece of information about the end user.
Threat Model Diagram for OAuth 2.0 Authorization code flow
The Below diagram illustrates the flow of data in OAuth 2.0 based application; the dashed lines represent the trust boundaries, where data could be potentially altered, exposed, and security measures need to be taken.
Tokens: OAuth makes extensive use of many kinds of tokens (access tokens, refresh tokens (aka opaque or bearer token), authorization “codes”, Assertion (aka self-contained token)).
An assertion typically has a duration, has an audience, and is digitally signed to ensure data integrity and origin authentication. It contains information about the user and the client.
A ‘bearer token’ is a token that can be used by any client who has received the token. Because mere possession is enough to use the token, it is important that communication between endpoints be secured to ensure that only authorized endpoints may capture the token
An access token is used by a client to access a resource. Access tokens typically have short life spans (minutes or hours) and may be refreshed using a refresh token.
A Refresh token can be used to grant longer access to resources without involving end-user authorization in a distributed environment. The refresh token is also a secret bound to the client identifier and client instance that originally requested the authorization.
This is ensured by the authorization process as follows:
- The resource owner and user agent safely deliver the authorization “code” to the client instance in the first place.
- The client uses it immediately in secure transport-level communications to the authorization server and then securely stores the long-lived refresh token.
- The client always uses the refresh token in secure transport- level communications to the authorization server to get an access token.
Scope: A scope represents the access authorization associated with a particular token with respect to resource servers, resources, and methods on those resources. Scope is a way to limit an app’s access to a user’s data.
Authorization “code” and Redirect URI: An authorization “code” represents the intermediate result of a successful end-user authorization process and is used by the client to obtain access and refresh tokens. To reduce this threat, short-lived authorization “codes” are passed instead of tokens and exchanged for tokens over a more secure direct connection between the client and the authorization server.
A redirect URI helps to detect malicious clients and prevents phishing attacks from clients attempting to trick the user into believing the phisher is the client.
Threat Model for vulnerable use cases
Depending on your implementation the threat model will vary significantly. Identify the assets, security controls, and threat agents.
Diagramming the system structure is critical. This creates a solid visual understanding of the system. The component diagram below illustrates the major components of the system and the interactions between those components.
Let’s do threat modeling for one of the vulnerable use case Open Redirect/Insufficient Redirect URI validation.
Some case authorization servers register redirect URI parameter instead of complete redirect URIs OR the authorization server doesn’t force to register the redirect URI. The authorization servers, then match the redirect URI parameter at the authorization endpoint with the registered URI at runtime.
Open redirects are a type of vulnerability that happen when an attacker can manipulate the value of this parameter and cause users to be redirected off-site. An attacker can append a malicious redirect URI and once the client authenticates to the system the victim will be redirected to an attacker-controlled site.
This vulnerability can lead to steal Access Tokens. If we talked about from the STRIDE perspective, Open Redirect threat will fall under multiple categories Spoofing, Tampering, Information Disclosure and Elevation of privilege if Access token have larger scope and special permissions.
Another use case we discuss here is CSRF attack
It is again one of the use cases of the above threat if the client doesn’t include a CSRF/state token while redirecting to Authorization server.
When the authorization server redirects the user back to the client, the client should check the CSRF token. This attack involves impersonating a user, So it affect the threat category Spoofing in STRIDE.
You can refer to the IETF RFC 6819 threat model to consider all the scenarios.
You can refer to the second part of the post for the threat pattern and attack type along with Security best practices here.
I hope you found this post useful. Feel free to provide any comment or feedback.
