OAuth Security Workshop 2021

1. © Hitachi, Ltd. 2021. All rights reserved.
Overall pictures of Identity provider mix-up attack patterns
and trade-offs between costs and effects for its mitigations
OAuth Security Workshop 2021
Hitachi, Ltd.
OSS Solution Center
Yoshiyuki Tabata

2. 1
© Hitachi, Ltd. 2021. All rights reserved.
About the speaker
• Consultant of API system
 For example, building a high-security banking API system.
• Contributor of 3scale (OSS of API Management)
 Developed features around security and access control.
 “Edge Limiting”, “RBAC”, “OAuth MTLS”, …
• Contributor of Keycloak (OSS of Identity Management)
 Developed features required for API use cases based on OAuth/OIDC.
 “Token Revocation”, “Refresh token setting per client”, …
Yoshiyuki Tabata
 Software Engineer
 OSS Solution Center, Hitachi, Ltd.
 GitHub: @y-tabata

3. 2
© Hitachi, Ltd. 2021. All rights reserved.
- This March, FAPI 1.0 Part 1 and Part 2 became OpenID final specifications.
"Identity provider mix-up attack" is described in Security Considerations.
- Although this attack is a very complex attack, there are few descriptions and no figures, so
it is difficult for implementers to grasp the overall picture of the attack.
- In this presentation, to grasp the overall picture of “Identity provider mix-up attack”, we
list and figure several patterns of this attack. And also we list mitigations and describe
which mitigation can be effective for which patterns.
Session Overview
In this attack, the client has registered multiple IdPs and one of them is a rogue IdP that returns the same client_id that belongs to one of the
honest IdPs. When a user clicks on a malicious link or visits a compromised site, an authorization request is sent to the rogue IdP. The rogue IdP
then redirects the client to the honest IdP that has the same client_id. If the user is already logged on at the honest IdP, then the authentication
may be skipped and a code is generated and returned to the client. Since the client was interacting with the rogue IdP, the code is sent to the
rogue IdP's token endpoint. At the point, the attacker has a valid code that can be exchanged for an access token at the honest IdP. See
OAUTHSEC for a detailed description of the attack.
This attack is mitigated by the use of OpenID Connect Hybrid Flow in which the honest IdP's issuer identifier is included as the value of iss or
JARM where the iss included in the response JWT. On receiving the authorization response, the client compares the iss value from the response
with the issuer URL of the IdP it sent the authorization request to (the rogue IdP). The client detects the conflicting issuer values and aborts the
transaction.

4. © Hitachi, Ltd. 2021. All rights reserved.
Contents
3
1. IdP mix-up attack patterns
 Overview
 Part A: before getting authz code
 Part B: after getting authz code
2. IdP mix-up attack mitigations for each pattern

5. © Hitachi, Ltd. 2021. All rights reserved.
Contents
4
1. IdP mix-up attack patterns
 Overview
 Part A: before getting authz code
 Part B: after getting authz code
2. IdP mix-up attack mitigations for each pattern

6. 5
© Hitachi, Ltd. 2021. All rights reserved.
Overview - Assumptions
- OAuth client interacts with at least two authorization servers.
- Assume a network attacker here.
- network attacker:
- who can manipulate the request in which the user sends her identity to the client
as well as the corresponding response to this request.
- web attacker:
- who does not intercept and manipulate network messages, only controls AIdP
(Attacker IdP).
- the network attacker has also the capability of the web attacker.
- Focus on authorization code flow here.

7. 6
© Hitachi, Ltd. 2021. All rights reserved.
Overview - Authorization code flow (1/2)
Browser Client Attacker IdP Honest IdP
client_id=“bbb”
client_id=“aaa”
Resource
Server
select IdP (HIdP)
authz request
authn
(skipped if already logged on)
authz response
token request
token response
API request
API response

8. 7
© Hitachi, Ltd. 2021. All rights reserved.
Overview - Authorization code flow (2/2)
Browser Client Attacker IdP Honest IdP
client_id=“bbb”
client_id=“aaa”
Resource
Server
select IdP (HIdP)
authz request
authn
(skipped if already logged on)
authz response
token request
token response
API request
API response
encrypted by
HTTPS, so cannot
be inspected or
altered by the
attacker
HTTPS is not
suggested, so can
be manipulated by
the attacker

9. 8
© Hitachi, Ltd. 2021. All rights reserved.
Overview - OAUTHSEC IdP mix-up attack (1/2)
Browser Client Attacker IdP Honest IdP
client_id=“bbb”
client_id=“aaa”
Resource
Server
select IdP (HIdP)
authz request (client_id=aaa)
authn
(skipped if already logged on)
authz response
token request
token request
token response
API request
API response
get authz code!
get access token!
get resource!
select IdP (AIdP)
authz request (client_id=bbb)
encrypted by
HTTPS, so cannot
be inspected or
altered by the
attacker
HTTPS is not
suggested, so can
be manipulated by
the attacker

10. 9
© Hitachi, Ltd. 2021. All rights reserved.
Overview - OAUTHSEC IdP mix-up attack (2/2)
Browser Client Attacker IdP Honest IdP
client_id=“bbb”
client_id=“aaa”
Resource
Server
select IdP (HIdP)
authz request (client_id=aaa)
authn
(skipped if already logged on)
authz response
token request
token request
token response
API request
API response
get authz code!
get access token!
get resource!
select IdP (AIdP)
authz request (client_id=bbb)
encrypted by
HTTPS, so cannot
be inspected or
altered by the
attacker
HTTPS is not
suggested, so can
be manipulated by
the attacker
Part A
before getting authz code
Part B
after getting authz code

11. © Hitachi, Ltd. 2021. All rights reserved.
Contents
10
1. IdP mix-up attack patterns
 Overview
 Part A: before getting authz code
 Part B: after getting authz code
2. IdP mix-up attack mitigations for each pattern

12. 11
© Hitachi, Ltd. 2021. All rights reserved.
Pattern A1: AIdP creates client’s new authz request
Browser Client Attacker IdP Honest IdP
client_id=“bbb”
client_id=“aaa”
select IdP (HIdP)
authz request (client_id=aaa)
authn
(skipped if already logged on)
authz response
token request
get authz code!
select IdP (AIdP)
authz request (client_id=bbb)
issue code to Client
delegate to AIdP
create client’s
new authz request

13. 12
© Hitachi, Ltd. 2021. All rights reserved.
Pattern A2: AIdP transfers client’s authz request
Browser Client Attacker IdP Honest IdP
client_id=“aaa”
client_id=“aaa”
select IdP (HIdP)
authz request (client_id=aaa)
authn
(skipped if already logged on)
authz response
token request
get authz code!
select IdP (AIdP)
authz request (client_id=aaa)
delegate to AIdP
issue code to Client
just transfer
without editing
same client ID as
registered to HIdP

14. 13
© Hitachi, Ltd. 2021. All rights reserved.
Pattern A3: AIdP creates AIdP’s authz request
Browser Client
client_id=“bbb”
client_id=“aaa”
select IdP (HIdP)
authz request (client_id=ccc)
authn
(skipped if already logged on)
authz response
token request
get authz code!
select IdP (AIdP)
authz request (client_id=bbb)
Attacker IdP Honest IdP
client_id=“ccc”
delegate to AIdP
issue code to AIdP
create AIdP’s
new authz request

15. © Hitachi, Ltd. 2021. All rights reserved.
Contents
14
1. IdP mix-up attack patterns
 Overview
 Part A: before getting authz code
 Part B: after getting authz code
2. IdP mix-up attack mitigations for each pattern

16. 15
© Hitachi, Ltd. 2021. All rights reserved.
Pattern B1: Attacker redeems code for access token
Client Attacker IdP Honest IdP
Resource
Server
token request
token response
API request
API response
get access token!
get resource!
token request
get authz code!

17. 16
© Hitachi, Ltd. 2021. All rights reserved.
Pattern B2: Attacker sends code to Client imitating a real login
Attacker’s
Browser Client Attacker IdP Honest IdP
select IdP (HIdP)
authz request
authn
(skipped if already logged on)
authz response
token request
token response
token request get authz code!
authz response
replace authz code
logged-in as
honest user!
start new flow

18. 17
© Hitachi, Ltd. 2021. All rights reserved.
IdP mix-up attack patterns
- Here, Part A contains 3 patterns and Part B contains 2 patterns.
- Whole patterns are 6 patterns, the combination of both parts' patterns.
- For each pattern, we consider which mitigation is effective.
# Part A: before getting authz code Part B: after getting authz code
1 A1: create client’s new authz request B1: redeem code for access token
2 A1: create client’s new authz request B2: send code to Client imitating a real login
3 A2: transfer client’s authz request B1: redeem code for access token
4 A2: transfer client’s authz request B2: send code to Client imitating a real login
5 A3: create AIdP’s authz request B1: redeem code for access token
6 A3: create AIdP’s authz request B2: send code to Client imitating a real login

19. © Hitachi, Ltd. 2021. All rights reserved.
Contents
18
1. IdP mix-up attack patterns
 Overview
 Part A: before getting authz code
 Part B: after getting authz code
2. IdP mix-up attack mitigations for each pattern

20. 19
© Hitachi, Ltd. 2021. All rights reserved.
Mitigation 1: Distinct redirect URIs
# Part 1:
before
Part 2:
after
1 A1: new
request
B1:
redeem
✔
2 A1: new
request
B2: imitate
login
✔
3 A2:
transfer
B1:
redeem
✔
4 A2:
transfer
B2: imitate
login
✔
5 A3: AIdP’s
request
B1:
redeem
✘
6 A3: AIdP’s
request
B2: imitate
login
✔
Browser Client AIdP HIdP
client_id=“bbb”
client_id=“aaa”
select IdP (HIdP)
authz request
(client_id=aaa)
authn
authz response
token request
save AIdP
select IdP (AIdP)
authz request
(client_id=bbb)
issue code to Client
delegate to AIdP
- Using a distinct redirect URI for each IdP is a well-known defense, for
example, written in OAuth Security BCP.
- Client saves IdP information to which sent authz request and checks the
matching between the distinct redirect URI for the IdP and the URI authz
response was received.
check redirect URI is AIdP’s
send to HIdP’s redirect URI

21. 20
© Hitachi, Ltd. 2021. All rights reserved.
Mitigation 1: Distinct redirect URIs
# Part 1:
before
Part 2:
after
1 A1: new
request
B1:
redeem
✔
2 A1: new
request
B2: imitate
login
✔
3 A2:
transfer
B1:
redeem
✔
4 A2:
transfer
B2: imitate
login
✔
5 A3: AIdP’s
request
B1:
redeem
✘
6 A3: AIdP’s
request
B2: imitate
login
✔
Browser Client
client_id=“bbb”
client_id=“aaa”
select IdP (HIdP)
authz request
(client_id=ccc)
authn
authz response
token request
save AIdP
select IdP (AIdP)
authz request
(client_id=bbb)
issue code to AIdP
delegate to AIdP
- In pattern #5, attacker can set AIdP's redirect URI to HIdP, so this
check is broken.
check redirect URI is AIdP’s
send to AIdP’s redirect URI
AIdP HIdP
client_id=“ccc”
get authz code!

22. 21
© Hitachi, Ltd. 2021. All rights reserved.
Mitigation 1: Distinct redirect URIs
# Part 1:
before
Part 2:
after
1 A1: new
request
B1:
redeem
✔
2 A1: new
request
B2: imitate
login
✔
3 A2:
transfer
B1:
redeem
✔
4 A2:
transfer
B2: imitate
login
✔
5 A3: AIdP’s
request
B1:
redeem
✘
6 A3: AIdP’s
request
B2: imitate
login
✔
Attacker’s
Browser Client
token request
- IdP usually ensures authz code was issued to the client, which is
written mandatory in RFC 6749.
- In pattern #6, HIdP should detect this mismatch.
AIdP HIdP
get authz code!
select IdP (HIdP)
authz request
authn
authz response
token request
token response
authz response
replace authz code
usually ensure code
was issued to Client
start new flow
client_id=“bbb”
client_id=“aaa”
client_id=“ccc”
issue code to AIdP

23. 22
© Hitachi, Ltd. 2021. All rights reserved.
Mitigation 2: Request object
# Part 1:
before
Part 2:
after
1 A1: new
request
B1:
redeem
✔
2 A1: new
request
B2: imitate
login
✔
3 A2:
transfer
B1:
redeem
✔
4 A2:
transfer
B2: imitate
login
✔
5 A3: AIdP’s
request
B1:
redeem
✘
6 A3: AIdP’s
request
B2: imitate
login
✔
Browser Client AIdP HIdP
client_id=“bbb”
client_id=“aaa”
select IdP (HIdP)
authz request
(client_id=aaa)
authn
select IdP (AIdP)
authz request
(client_id=bbb)
issue code to Client
delegate to AIdP
- Using request object (JWT including whole request parameters) in
authz request, prevents tampering with request parameters.
- Request object must be signed and HIdP must deny authz request
not contains request object.
check sig of request object

24. 23
© Hitachi, Ltd. 2021. All rights reserved.
Mitigation 2: Request object
# Part 1:
before
Part 2:
after
1 A1: new
request
B1:
redeem
✔
2 A1: new
request
B2: imitate
login
✔
3 A2:
transfer
B1:
redeem
✔
4 A2:
transfer
B2: imitate
login
✔
5 A3: AIdP’s
request
B1:
redeem
✘
6 A3: AIdP’s
request
B2: imitate
login
✔
Browser Client AIdP HIdP
client_id=“aaa”
client_id=“aaa”
select IdP (HIdP)
authn
select IdP (AIdP)
issue code to Client
delegate to AIdP
- Request object must contain "iss" and "aud".
- Then, HIdP can detect the request object is for AIdP in patterns
like #3 and #4.
check aud of request object
authz request
(client_id=aaa)
authz request
(client_id=aaa)
just transfer
without editing

25. 24
© Hitachi, Ltd. 2021. All rights reserved.
Mitigation 2: Request object
# Part 1:
before
Part 2:
after
1 A1: new
request
B1:
redeem
✔
2 A1: new
request
B2: imitate
login
✔
3 A2:
transfer
B1:
redeem
✔
4 A2:
transfer
B2: imitate
login
✔
5 A3: AIdP’s
request
B1:
redeem
✘
6 A3: AIdP’s
request
B2: imitate
login
✔
Browser Client AIdP HIdP
select IdP (HIdP)
authn
select IdP (AIdP)
delegate to AIdP
- In pattern #5, attacker can create his own request object, so this
check is broken.
authz request
(client_id=ccc)
authz request
(client_id=aaa)
client_id=“bbb”
client_id=“aaa”
client_id=“ccc”
authz response
token request
get authz code!
issue code to AIdP
check AIdP’s request object

26. 25
© Hitachi, Ltd. 2021. All rights reserved.
Mitigation 2: Request object
# Part 1:
before
Part 2:
after
1 A1: new
request
B1:
redeem
✔
2 A1: new
request
B2: imitate
login
✔
3 A2:
transfer
B1:
redeem
✔
4 A2:
transfer
B2: imitate
login
✔
5 A3: AIdP’s
request
B1:
redeem
✘
6 A3: AIdP’s
request
B2: imitate
login
✔
Attacker’s
Browser Client
token request
AIdP HIdP
get authz code!
select IdP (HIdP)
authz request
authn
authz response
token request
token response
authz response
replace authz code
usually ensure code
was issued to Client
start new flow
client_id=“bbb”
client_id=“aaa”
client_id=“ccc”
issue code to AIdP
- IdP usually ensures authz code was issued to the client, which is
written mandatory in RFC 6749.
- In case #6, HIdP should detect this mismatch.

27. 26
© Hitachi, Ltd. 2021. All rights reserved.
Mitigation 3: Strong client authentication
# Part 1:
before
Part 2:
after
1 A1: new
request
B1:
redeem
✔
2 A1: new
request
B2: imitate
login
✘
3 A2:
transfer
B1:
redeem
✔
4 A2:
transfer
B2: imitate
login
✘
5 A3: AIdP’s
request
B1:
redeem
✘
6 A3: AIdP’s
request
B2: imitate
login
✔
AIdP
token request
- Using strong client authn prevents redeeming authz code for access
token even if authz code was provided to attacker.
- Strong client authn are private_key_jwt, tls_client_auth,
self_signed_tls_client_auth.
- client_secret_post, client_secret_basic, and client_secret_jwt are
acceptable if client is capable of maintaining confidentiality of client
secret and does not reuse the same client secret in multiple IdPs.
- Public client is out of the question.
- HIdP must accept strong client authn only.
HIdP
Resource
Server
get authz code! issue code to Client
token request
token response
client_id=“bbb”
client_id=“aaa”
check client authn
Client

28. 27
© Hitachi, Ltd. 2021. All rights reserved.
Mitigation 3: Strong client authentication
# Part 1:
before
Part 2:
after
1 A1: new
request
B1:
redeem
✔
2 A1: new
request
B2: imitate
login
✘
3 A2:
transfer
B1:
redeem
✔
4 A2:
transfer
B2: imitate
login
✘
5 A3: AIdP’s
request
B1:
redeem
✘
6 A3: AIdP’s
request
B2: imitate
login
✔
AIdP
token request
- In pattern #5, HIdP verifies AIdP successfully authenticated using
AIdP's client credential, so this check is broken.
HIdP
Resource
Server
get authz code!
token request
token response
API request
API response
get access token!
get resource!
issue code to AIdP
check client authn
Client
client_id=“bbb”
client_id=“aaa”
client_id=“ccc”

29. 28
© Hitachi, Ltd. 2021. All rights reserved.
Mitigation 3: Strong client authentication
# Part 1:
before
Part 2:
after
1 A1: new
request
B1:
redeem
✔
2 A1: new
request
B2: imitate
login
✘
3 A2:
transfer
B1:
redeem
✔
4 A2:
transfer
B2: imitate
login
✘
5 A3: AIdP’s
request
B1:
redeem
✘
6 A3: AIdP’s
request
B2: imitate
login
✔
- In patterns #2 and #4, client uses its client credential, so this
check is broken.
Attacker’s
Browser Client
token request
AIdP HIdP
get authz code!
select IdP (HIdP)
authz request
authn
authz response
token request
token response
authz response
replace authz code
usually ensure code
was issued to Client
start new flow issue code to Client
logged-in as
honest user!
client_id=“bbb”
client_id=“aaa”

30. 29
© Hitachi, Ltd. 2021. All rights reserved.
Mitigation 3: Strong client authentication
# Part 1:
before
Part 2:
after
1 A1: new
request
B1:
redeem
✔
2 A1: new
request
B2: imitate
login
✘
3 A2:
transfer
B1:
redeem
✔
4 A2:
transfer
B2: imitate
login
✘
5 A3: AIdP’s
request
B1:
redeem
✘
6 A3: AIdP’s
request
B2: imitate
login
✔
Attacker’s
Browser Client
token request
AIdP HIdP
get authz code!
select IdP (HIdP)
authz request
authn
authz response
token request
token response
authz response
replace authz code
usually ensure code
was issued to Client
start new flow
client_id=“bbb”
client_id=“aaa”
client_id=“ccc”
issue code to AIdP
- IdP usually ensures authz code was issued to the client, which is
written mandatory in RFC 6749.
- In case #6, HIdP should detect this mismatch.

31. 30
© Hitachi, Ltd. 2021. All rights reserved.
Mitigation 4: Client-based access control
# Part 1:
before
Part 2:
after
1 A1: new
request
B1:
redeem
✔
2 A1: new
request
B2: imitate
login
✘
3 A2:
transfer
B1:
redeem
✔
4 A2:
transfer
B2: imitate
login
✘
5 A3: AIdP’s
request
B1:
redeem
✔
6 A3: AIdP’s
request
B2: imitate
login
✔
AIdP
token request
- Using the mapping information of clients and resources, resource server
checks the requested resource is allowed to the requesting client or not.
- The requesting client can be usually identified with "azp" claim bound to
access token, but if so the attack is not detected in patterns #1 and #3.
- If the requesting client is identified with "cnf" claim (defined by RFC
8705) which contains client cert hash, the attack can be detected in
patterns #1 and #3.
HIdP
Resource
Server
get authz code!
token request
token response
API request
API response
get access token!
issue code to Client
Client
client_id=“bbb”
client_id=“aaa”
client-based access control
(with cnf claim)
check client authn

32. 31
© Hitachi, Ltd. 2021. All rights reserved.
Mitigation 4: Client-based access control
# Part 1:
before
Part 2:
after
1 A1: new
request
B1:
redeem
✔
2 A1: new
request
B2: imitate
login
✘
3 A2:
transfer
B1:
redeem
✔
4 A2:
transfer
B2: imitate
login
✘
5 A3: AIdP’s
request
B1:
redeem
✔
6 A3: AIdP’s
request
B2: imitate
login
✔
AIdP
token request
- In pattern #5, implementing appropriate client-based access
control, resource server can deny access from AIdP.
HIdP
Resource
Server
get authz code!
token request
token response
API request
API response
get access token!
issue code to AIdP
Client
client-based access control
check client authn
client_id=“bbb”
client_id=“aaa”
client_id=“ccc”

33. 32
© Hitachi, Ltd. 2021. All rights reserved.
Mitigation 4: Client-based access control
# Part 1:
before
Part 2:
after
1 A1: new
request
B1:
redeem
✔
2 A1: new
request
B2: imitate
login
✘
3 A2:
transfer
B1:
redeem
✔
4 A2:
transfer
B2: imitate
login
✘
5 A3: AIdP’s
request
B1:
redeem
✔
6 A3: AIdP’s
request
B2: imitate
login
✔
- In patterns #2 and #4, resource server is not there, so this check
has no effect.
Attacker’s
Browser Client
token request
AIdP HIdP
get authz code!
select IdP (HIdP)
authz request
authn
authz response
token request
token response
authz response
replace authz code
usually ensure code
was issued to Client
start new flow issue code to Client
logged-in as
honest user!
client_id=“bbb”
client_id=“aaa”

34. 33
© Hitachi, Ltd. 2021. All rights reserved.
Mitigation 4: Client-based access control
# Part 1:
before
Part 2:
after
1 A1: new
request
B1:
redeem
✔
2 A1: new
request
B2: imitate
login
✘
3 A2:
transfer
B1:
redeem
✔
4 A2:
transfer
B2: imitate
login
✘
5 A3: AIdP’s
request
B1:
redeem
✔
6 A3: AIdP’s
request
B2: imitate
login
✔
Attacker’s
Browser Client
token request
AIdP HIdP
get authz code!
select IdP (HIdP)
authz request
authn
authz response
token request
token response
authz response
replace authz code
usually ensure code
was issued to Client
start new flow
client_id=“bbb”
client_id=“aaa”
client_id=“ccc”
issue code to AIdP
- IdP usually ensures authz code was issued to the client, which is
written mandatory in RFC 6749.
- In case #6, HIdP should detect this mismatch.

35. 34
© Hitachi, Ltd. 2021. All rights reserved.
Mitigation 5: New authz response parameters
# Part 1:
before
Part 2:
after
1 A1: new
request
B1:
redeem
✔
2 A1: new
request
B2: imitate
login
✔
3 A2:
transfer
B1:
redeem
✔
4 A2:
transfer
B2: imitate
login
✔
5 A3: AIdP’s
request
B1:
redeem
✔
6 A3: AIdP’s
request
B2: imitate
login
✔
Browser Client AIdP HIdP
client_id=“bbb or aaa”
client_id=“aaa”
select IdP (HIdP)
authz request
(client_id=aaa)
select IdP (AIdP)
authz request
(client_id=bbb or aaa)
issue code to Client
delegate to AIdP
- Using "iss" parameter and "client_id" parameter in authz response,
defined by OAuth 2.0 Mix-Up Mitigation (internet-draft), makes detect
mismatch of the combination of IdP and client.
- Client must implement "iss" parameter and "client_id" parameter check.
authn
authz response
token request
check iss and client_id param
save AIdP

36. 35
© Hitachi, Ltd. 2021. All rights reserved.
Mitigation 5: New authz response parameters
# Part 1:
before
Part 2:
after
1 A1: new
request
B1:
redeem
✔
2 A1: new
request
B2: imitate
login
✔
3 A2:
transfer
B1:
redeem
✔
4 A2:
transfer
B2: imitate
login
✔
5 A3: AIdP’s
request
B1:
redeem
✔
6 A3: AIdP’s
request
B2: imitate
login
✔
Browser Client AIdP HIdP
select IdP (HIdP)
authz request
(client_id=ccc)
select IdP (AIdP)
authz request
(client_id=bbb)
issue code to AIdP
delegate to AIdP
- The result is the same if AIdP was registered to HIdP.
Combination of IdP and client is different from client assumes,
client can abort interaction.
authn
authz response
token request
check iss and client_id param
client_id=“bbb”
client_id=“aaa”
client_id=“ccc”
save AIdP

37. 36
© Hitachi, Ltd. 2021. All rights reserved.
Mitigation 6: ID token as detached signature
# Part 1:
before
Part 2:
after
1 A1: new
request
B1:
redeem
✔
2 A1: new
request
B2: imitate
login
✔
3 A2:
transfer
B1:
redeem
✔
4 A2:
transfer
B2: imitate
login
✔
5 A3: AIdP’s
request
B1:
redeem
✔
6 A3: AIdP’s
request
B2: imitate
login
✔
- Using ID token as detached signature, defined by OIDC Core 1.0 and
OAuth 2.0 Multiple Response Type Encoding Practices, i.e. specify
"id_token" to response_type and get ID token in authz response, makes
detect mismatch of the combination of IdP and client.
Browser Client AIdP HIdP
client_id=“bbb or aaa”
client_id=“aaa”
select IdP (HIdP)
authz request
(client_id=aaa)
select IdP (AIdP)
authz request
(client_id=bbb or aaa)
issue code to Client
delegate to AIdP
authn
authz response
token request
save AIdP
response_type=code id_token
check iss and aud of ID token

38. 37
© Hitachi, Ltd. 2021. All rights reserved.
Mitigation 6: ID token as detached signature
# Part 1:
before
Part 2:
after
1 A1: new
request
B1:
redeem
✔
2 A1: new
request
B2: imitate
login
✔
3 A2:
transfer
B1:
redeem
✔
4 A2:
transfer
B2: imitate
login
✔
5 A3: AIdP’s
request
B1:
redeem
✔
6 A3: AIdP’s
request
B2: imitate
login
✔
- The result is the same if AIdP was registered to HIdP.
Combination of IdP and client is different from client assumes,
client can abort interaction.
Browser Client AIdP HIdP
select IdP (HIdP)
authz request
(client_id=ccc)
select IdP (AIdP)
authz request
(client_id=bbb)
issue code to AIdP
delegate to AIdP
authn
authz response
token request
save AIdP
response_type=code id_token
check iss and aud of ID token
client_id=“bbb”
client_id=“aaa”
client_id=“ccc”

39. 38
© Hitachi, Ltd. 2021. All rights reserved.
Mitigation 7: JARM
# Part 1:
before
Part 2:
after
1 A1: new
request
B1:
redeem
✔
2 A1: new
request
B2: imitate
login
✔
3 A2:
transfer
B1:
redeem
✔
4 A2:
transfer
B2: imitate
login
✔
5 A3: AIdP’s
request
B1:
redeem
✔
6 A3: AIdP’s
request
B2: imitate
login
✔
- By following JARM, JWT Secured Authorization Response Mode
for OAuth 2.0, i.e. specify such as "query.jwt" to response_mode
and get JWT in authz response, makes detect mismatch of the
combination of IdP and client.
Browser Client AIdP HIdP
client_id=“bbb or aaa”
client_id=“aaa”
select IdP (HIdP)
authz request
(client_id=aaa)
select IdP (AIdP)
authz request
(client_id=bbb or aaa)
issue code to Client
delegate to AIdP
authn
authz response
token request
save AIdP
response_mode=query.jwt
check iss and aud of JWT

40. 39
© Hitachi, Ltd. 2021. All rights reserved.
Mitigation 7: JARM
# Part 1:
before
Part 2:
after
1 A1: new
request
B1:
redeem
✔
2 A1: new
request
B2: imitate
login
✔
3 A2:
transfer
B1:
redeem
✔
4 A2:
transfer
B2: imitate
login
✔
5 A3: AIdP’s
request
B1:
redeem
✔
6 A3: AIdP’s
request
B2: imitate
login
✔
- The result is the same if AIdP was registered to HIdP.
Combination of IdP and client is different from client assumes,
client can abort interaction.
Browser Client AIdP HIdP
select IdP (HIdP)
authz request
(client_id=ccc)
select IdP (AIdP)
authz request
(client_id=bbb)
issue code to AIdP
delegate to AIdP
authn
authz response
token request
save AIdP
response_mode=query.jwt
check iss and aud of JWT
client_id=“bbb”
client_id=“aaa”
client_id=“ccc”

41. 40
© Hitachi, Ltd. 2021. All rights reserved.
IdP mix-up attack mitigations for each pattern
- M5, M6, and M7 prevent IdP mix-up attack completely.
- FAPI 1.0 recommends satisfying M6 or M7.
# Part 1:
before
Part 2:
after
M1:
distinct
redirect
URIs
M2:
request
object
M3: strong
client
authn
M4: client-
based
access
control
M5: new
authz
params
M6:
detached
sig
M7: JARM
1 A1: new
request
B1:
redeem
✔ ✔ ✔ ✔ ✔ ✔ ✔
2 A1: new
request
B2: imitate
login
✔ ✔ ✘ ✘ ✔ ✔ ✔
3 A2:
transfer
B1:
redeem
✔ ✔ ✔ ✔ ✔ ✔ ✔
4 A2:
transfer
B2: imitate
login
✔ ✔ ✘ ✘ ✔ ✔ ✔
5 A3: AIdP’s
request
B1:
redeem
✘ ✘ ✘ ✔ ✔ ✔ ✔
6 A3: AIdP’s
request
B2: imitate
login
✔ ✔ ✔ ✔ ✔ ✔ ✔

42. 41
© Hitachi, Ltd. 2021. All rights reserved.
Summary
• We described 6 patterns of IdP mix-up attack, 7 mitigations of the attack,
and which mitigation can be effective for which patterns.
• The best mitigation is that client interacts with only one authorization
server, but it may be difficult to accept it considering usability.
• Effectiveness of mitigations described here was only focusing on IdP mix-up
attack, so when adapting to real environment, it is necessary to consider
other factors combinedly such as effectiveness to other attacks.

43. 42
© Hitachi, Ltd. 2021. All rights reserved.
Trademarks
• OpenID is a trademark or registered trademark of OpenID Foundation in the United States and other
countries.
• GitHub is a trademark or registered trademark of GitHub, Inc. in the United States and other
countries.
• Other brand names and product names used in this material are trademarks, registered trademarks,
or trade names of their respective holders.

45. 44
© Hitachi, Ltd. 2021. All rights reserved.
OAUTHSEC IdP mix-up attack (post ver.)
Browser Client Attacker IdP Honest IdP
client_id=“bbb”
client_id=“aaa”
select IdP (HIdP)
authz request (client_id=aaa)
authn
(skipped if already logged on)
authz response
token request
get authz code!
select IdP (AIdP)
authz request (client_id=bbb)

46. 45
© Hitachi, Ltd. 2021. All rights reserved.
OAUTHSEC IdP mix-up attack (variant)
Browser Client Attacker IdP Honest IdP
client_id=“bbb”
client_id=“aaa”
select IdP (AIdP)
authz request (client_id=aaa)
authn
(skipped if already logged on)
authz response
token request
get authz code!
authz request (client_id=bbb)

47. 46
© Hitachi, Ltd. 2021. All rights reserved.
Pattern 4: AIdP transfers client’s authz request
Browser Client
client_id=“bbb”
client_id=“aaa”
select IdP (HIdP)
authz request (client_id=bbb)
authn
(skipped if already logged on)
authz response
token request
get authz code!
select IdP (AIdP)
authz request (client_id=bbb)
Attacker IdP Honest IdP
client_id=“bbb”
just transfer without editing
issue code to AIdP
delegate to AIdP