NOTE (put it into the introduction): We are protecting the protocol itself - not only endpoints. The flow at one endpoint might lead to a breach at another endpoint.
About this document
This document is based on the work of security researcher Daniel Fett, which draws heavily on the formal analysis method developed by Ralf Kuesters, Pedram Hosseyni at the university of Stuttgart and Daniel Fett at yes.com.
Their work has been adopted by IETF through the OAuth Security BCP, and by OIDF in the standardized security profile FAPI.
HelseID has used this model when selecting a security profile suitable for the health sector in Norway.
What is an attacker model?
An Attacker Model is a generic description of how an attacker thinks. Attacker modelling can include threat modeling, abuse case development and refinement, data classification, and technology-specific attack patterns.
| Info |
|---|
What? Is OAuth insecure?The security of OAuth 2.0 is well understood and for specific attackers, even formally proven. High-stakes environments like e-health obviously have very high security requirements, and OAuth has shown that it can deal with these. But, given a strong enough attacker any protocol is insecure. This document helps to assess the security mechanisms needed to defend against strong and very strong attackers. |
How can you use this attack model?
This document gives an overview of a strong, but reasonable attacker model that can be used to determine a suitable level of protection for using OAuth and OpenID Connect.
The attacker model can be used to decide the specific protection mechanisms that need to be applied.
It further provides information on non-repudiation requirements that can be introduced on top of the attacker model to determine the need for additional message-level signing mechanisms.
A list of attacks is provided to map the attacker model to concrete attacks. As usual, the list cannot be exhaustive, but documents the currently known attacks.
Assumptions for this attack model
TLS
We assume the following concerning TLS:
TLS connections are not broken, and data integrity and confidentiality is ensured.
The correct public keys are used to establish TLS connections.
Private keys are not known to attackers (except for two specific scenarios).
JWKS
We assume the following concerning JWKS:
Key distribution mechanisms work as intended
Encryption and signature verification keys of uncompromised parties are retrieved from the correct endpoints
Browsers and devices
We assume that devices and browsers that the honest actors use is not compromised
Authorization Servers
We assume that the integrity of honest AS's authorization endpoints is given at all times.
Otherwise, attackers could trivially read and misuse authentication credentials. The same applies to a compromised browser or operating system.
The capabilities that are realistic, reading authorization requests or responses and injecting authorization requests, are captured by A3a, A3b, and A1, respectively.