OAuth Attacker Model Cheat Sheet

	A	B
1	OAuth Attacker Model Cheat Sheet
2
3	What is this?
4	This document gives an overview of a strong, but reasonable attacker model that can be used to determine the intended level of protection when designing an OAuth or OIDC profile. The attacker model can then be used to decide which specific protection mechanisms need to be applied.	→ Attacker Model
5	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.	→ Non-Repudiation Requirements
6	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.	→ Known Attacks
7
8	Attacks? Is OAuth insecure?
9	The security of OAuth 2.0 is well understood and for specific attackers, even formally proven. High-stakes environments like banking 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 sheet helps to assess the security mechanisms needed to defend against strong and very strong attackers.	Example: Security Proof for OAuth 2.0
10
11	Author:
12	Daniel Fett, yes.com, danielf@yes.com	https://danielfett.de
13	Last updated: 2019-11-26	https://yes.com
14
15	Acknowledgements:
16	These attacker models draw heavily from the formal analysis of the first FAPI versions conducted by Pedram Hosseyni, Ralf Kuesters (both University of Stuttgart), and Daniel Fett (yes.com).
17
18	Changelog:
19	2019-12-20: Removed attackers A4a and A4b
20	We must assume that the integrity of honest AS's authorization endpoints is given at all times. Otherwise, attackers could trivially read and misuse authentication credentials. Same for 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.
21	2019-12-20: Conflate attackers A5 and A6
22	As above, integrity of the AS must be given at all times, else much easier attacks that are out of the scope of what OAuth can protect against are possible. Therefore, the integrity of the token endpoint must be given at all times. A5 (former A5 and A6) is now described more precisely: An attacker can make a client developer use a different token endpoint (different URI), but not read/tamper with requests to/from the original token endpoint.
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100