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.
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.