0
votes

What is preventing the following scenario:

  • Attacker downloads legitimate app that makes a legitimate OAuth 2.0 Authorization Grant to a desired resource
  • Attacker records the client_id and redirect_uri
  • Attacker creates phony app in the image of the real thing
  • Victim downloads phony app and begins OAuth 2 flow for desired resource
  • Phony app provides identical client_id and redirect_uri as legitimate app
  • Victim authenticates and authorizes use of desired resource
  • Phony app catches the redirect without ever hitting URL (I know iOS can do this) and securing its contained authorization code.
  • Phony app now has access to desired resource "in the name" of a legitimate app

Is there any way to actually validate the identity of an app making an authorization request when using a public client (no client_secret)?

1
How does Phony app catches the redirect without ever hitting URL ? If this is within the app itself then the app could have simply harvested the credentials when the flow was redirected to the idP.SilverlightFox

1 Answers

1
votes

There is no inclusive protection against that threat as the OAuth 2.0 security considerations spec acknowledges: https://www.rfc-editor.org/rfc/rfc6819#section-5.5. It acknowledges that the user plays an important role here. Some remarks though:

App installation control via Mobile Device Management may be applicable in some (enterprise) use cases to mitigate this.

Dynamic Client registration (http://openid.net/specs/openid-connect-registration-1_0.html) may be used to generate a per-instance client secret so that after registration the Client is a confidential Client. Yet the the app integrity question then still exists (only) in the initial bootstrapping/registration phase.