0

It's a know problem that Instant Flow struggles from confused problem, so you have to check whether access_token you received was given to your application.

I always considered it's not a problem for Authorization Code flow but in this answer it was mentioned it is not so and you have to verify token even in Authorization Token flow.

But honestly I can't figure out a workflow where it's necessary. Like we receive a code and then make direct request for a token (specifying client_secret). I don't understand how we could be forced to use a wrong token in this flow.

Community
  • 1
  • 1
SiberianGuy
  • 24,674
  • 56
  • 152
  • 266

1 Answers1

1

The answer that you refer to talks about an access_token delivered to a Resource Server. That is also in general where the "confused deputy" issue applies.

In your post you refer to the Authorization Code delivered to the Client. That is different and does not suffer from the same confused deputy attack as described.

It should be noted though that the Authorization Code grant type may be vulnerable to a related attack ("Authorization Server Mixup") if the Client talks to multiple Authorization Servers (AS) somewhat for the same reason: the Client is not able to detect if the Authorization Code is actually issued by the AS that it thinks it talks to. Registering a Redirect URI that is specific for each AS addresses this.

Community
  • 1
  • 1
Hans Z.
  • 50,496
  • 12
  • 102
  • 115