Tonight’s light reading
OAuth 2.0 Authorization Server Issuer Identification
OAuth 2.0 Authorization Server Issuer Identification
Okay, so this is something that addresses the conversation in GNAP right now.
A mix-up attack is where a client, which interacts with multiple AS uses one that has become compromised (AAS) and it is proxying & rewriting from an uncompromised AS (HAS)
A mix-up attack is where a client, which interacts with multiple AS uses one that has become compromised (AAS) and it is proxying & rewriting from an uncompromised AS (HAS)
I wish acronyms weren’t explained more often
JARM (Jwt secured Access Response Mode) is such a weird name to me
Yeah I guess so. If the client is just following redirects (and it so happens to start with the Adversary’s AS (AAS) and ends with the Honest AS (HAS), the mix up isn’t actually a MITM attack, but something else in the protocol.
So my earlier interpretation of a mix up was off.
So my earlier interpretation of a mix up was off.
Looking back at the GNAP graph, I see where I mixed things up (oh the pun).
While the AAS does contact the HAS and rewrites the response, the client also communicates with the HAS using the modified interaction / session.
So, a bit of both I guess.
While the AAS does contact the HAS and rewrites the response, the client also communicates with the HAS using the modified interaction / session.
So, a bit of both I guess.
Wrapping up: OAuth 2.0 Authorization Server Issuer Identification appears to help outside of JARM as a mitigation to mix up attacks. While the introduction does not sufficiently edify me on the circumstances this mitigation applies to, the proposal is minimal and sound.
@threadreaderapp unroll
• • •
Missing some Tweet in this thread? You can try to
force a refresh
