Hi Torsten, > > The attacker will not get the access and refresh tokens > > without the client_id, but doesn't need to. > > whether this is an obstacle mainly depends on whether a > client secret is associated with this client_id.
You're right, I meant to say client_secret, not client_id. > ... > > > The attacker can impersonate the user, log in to the > > client if the protocol is used for social login as in > > "log in with Facebook", and use the client to obtain > > protected resources of the legitimate user and deliver > > them to the attacker. The attacker never sees an access > > token, but the client gets the access token and uses it > > for the benefit of the attacker. > > You describe the potential impact of a spoofing attack on > the client web site, correct? Is this specific to OAuth? I > ask because the focus of the document is on OAuth specific > threats. I was talking about your scenario where an attacker uses DNS spoofing or ARP spoofing to get the authorization code, and more generally about an attacker obtaining the authorization code by any means. It's definitely specific to OAuth. > ... > > > The authorization code is a credential that provides > > access to the user's protected resources (via the > > client) and allows the user to log in to the client (in > > a social-login scenario). Sending it without TLS > > protection, as OAuth 2.0 does, is tantamount to sending > > a user password without TLS protection. > > Hmmh, OAuth 2.0 is just a protocol. Implementations decide > to send/receive authorization codes with or without TLS > protection. Having the security threat model now, the > OAuth 2.0 spec could declare TLS protection a MUST for the > redirect back to the clients. I think that's what you > would like to see? Yes, I'm saying that transmission of the authorization code to the client must be protected by TLS, just like you say that transmission of the authorization code to the authorization server must be protected by TLS (section 4.4.1.2) and all transmissions of the access token must be protected by TLS (section 4.1.3), and just like the bearer token specification says that transmission of the token to a resource server must be protected by TLS (section 3.2). The thing to keep in mind is that the authorization code deserves as much protection as the access token because an attacker can use the authorization code to cause the client to obtain the access token and use it for the attacker's benefit. Plus, the attacker can use the authorization code to log in to the client in a social login scenario, so the authorization code is arguably more valuable than the access token to the attacker. Francisco
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
