Changes

In some cases, e.g. desktop software or mobile-device apps, the consumer is not hosted on a remote server. Instead, it runs entirely on each user's device. In this scenario, it is not possible for the data host to truly authenticate the consumer: an attacker can extract all secrets from the software binary. ClosedSome controls can make it harder to extract the secret, but it is always feasible. To integrate the desktop/device software with the web-source based data host, it is typical for the consumer software distributed in to spawn a web browser through which the user authenticates and grants permission. Things are a tightly controlled environmentlittle bit tricky for the second redirect, efrom the data host back to the consumer.g. iOS In some cases, notably mobile devices, appscan register protocol names, have an inherent advantage here if they wish so that redirecting to keep secret credentials<tt>appname: though //back_from_auth?code=..</tt> will trigger the switch back to the app, which can then complete the credentialing dance using the obtained code. OAuth 2.0 defines a more integrated flow called the Implicit Authorization Grant. The data-consumer software is expected to embed a web browser and direct it is still possible to extract secret credentialsthe data host for authorization. In the second redirect, itthe data host sends the consumer's embedded browser to a good bit more difficultwell-defined URL with the <tt>access_token</tt> positioned in the fragment identifier. The data consumer is expected to sniff this URL, extract the <tt>access_token</tt> and close its embedded web browser.