3 ms·

The attack scenario occurs when the service (e.g. Facebook) wants to redirect the user back to the client (e.g. your website). That request contains an authoriz

The attack scenario occurs when the service (e.g. Facebook) wants to redirect the user back to the client (e.g. your website). That request contains an authorization code which is coupled to the client secret (it's only usable if you have the client secret). In server-side application this isn't a problem as the client secret is on the server-side. However, for mobile apps you'll have to embed the client secret into the application and it's relatively easy to find it. This can be combined with registering a custom scheme handler and thus hijack the redirect URL. If you're able to register your app as a handler for "airbnb://", then your app will be opened once the service redirects back. And if you've figured out the client secret then you can finalize the authorization step and get an access token. The difference in PKCE is that the client generates a unique random secret (code verifier) before it starts everything. The authorization is then coupled to the hash of the secret (code challenge), and for the authorization code to be converted into an access token the client needs to reveal the original code verifier.

filleokus 6y ago
Huh, I never thought about this. I would guess an active MITM attack (breaking TLS) would work as well, since the server returns a 301 or something to airbnb:// which we could intercept and act on?
treve 6y ago
You don't _need_ a client secret for authorization_code though, do you? This part of the premise didn't make sense to me, and especially people opting for implicit as an alternative instead, because it still has this 'intercept' problem, except instead of a 1-time code, you get a long lived access token.
- different_sort 6y ago
  Implicit grant is depecrated, in the forthcoming OAuth 2.1 [1] standard this is solidified. We start using the language "public client" and "private client", where a public client is an OAuth client like a mobile app or SPA that does not have a client secret, but has an access token delegated to it(+optional refresh token). Public clients must use implicit+PKCE. Private clients are what we would have previously thought of as an Authorization code grant client where a server process has an access token to take actions on behalf of a user. Depending on the OAuth use case, maintainers of the system may need to keep track of what clients are public or private, and limit their entitlements accordingly. Public clients have the obvious issue that they're on an end-user device and thus the tokens may be stolen, proposed standards like JWT DPOP [2] and token binding [3] aim to address this. [1] https://oauth.net/2.1/ https://oauth.net/2.1/ [2] https://datatracker.ietf.org/doc/draft-ietf-oauth-dpop/ https://datatracker.ietf.org/doc/draft-ietf-oauth-dpop/ [3] https://tools.ietf.org/html/rfc8471 https://tools.ietf.org/html/rfc8471 . Though I should say token binding does seem like it will never go anywhere. This space is insane and hard to keep up with.

filleokus 6y ago

Huh, I never thought about this. I would guess an active MITM attack (breaking TLS) would work as well, since the server returns a 301 or something to airbnb:// which we could intercept and act on?

treve 6y ago

You don't _need_ a client secret for authorization_code though, do you? This part of the premise didn't make sense to me, and especially people opting for implicit as an alternative instead, because it still has this 'intercept' problem, except instead of a 1-time code, you get a long lived access token.

different_sort 6y ago
Implicit grant is depecrated, in the forthcoming OAuth 2.1 [1] standard this is solidified. We start using the language "public client" and "private client", where a public client is an OAuth client like a mobile app or SPA that does not have a client secret, but has an access token delegated to it(+optional refresh token). Public clients must use implicit+PKCE. Private clients are what we would have previously thought of as an Authorization code grant client where a server process has an access token to take actions on behalf of a user. Depending on the OAuth use case, maintainers of the system may need to keep track of what clients are public or private, and limit their entitlements accordingly. Public clients have the obvious issue that they're on an end-user device and thus the tokens may be stolen, proposed standards like JWT DPOP [2] and token binding [3] aim to address this. [1] https://oauth.net/2.1/ https://oauth.net/2.1/ [2] https://datatracker.ietf.org/doc/draft-ietf-oauth-dpop/ https://datatracker.ietf.org/doc/draft-ietf-oauth-dpop/ [3] https://tools.ietf.org/html/rfc8471 https://tools.ietf.org/html/rfc8471 . Though I should say token binding does seem like it will never go anywhere. This space is insane and hard to keep up with.