668
edits
Privacy/BestPractices/OAuth: Difference between revisions
→Device-based
| Line 49: | Line 49: | ||
=== Device-based === | === Device-based === | ||
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. | 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. Some controls can make it harder to extract the secret, but it is always feasible. | ||
To integrate the desktop/device software with the web-based data host, it is typical for the consumer software to spawn a web browser through which the user authenticates and grants permission. Things are a little bit tricky for the second redirect, from the data host back to the consumer. In some cases, notably mobile devices, apps can register protocol names, so that redirecting to <tt>appname://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 to the data host for authorization. In the second redirect, the data host sends the consumer's embedded browser to a well-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. | |||
=== Hybrid === | === Hybrid === | ||