Bug #4692
Updated by Tom Clegg over 9 years ago
Background: A third party Any web service client can use a link or redirect to send a user's browser go through the login process, which culminates in the third party receiving process and receive an API token. This facilitates user-deployed applications against While this is convenient for developer workbench instances to access a production API services, but it also gives a malicious third party server, this could may allow an opportunity to trick a user into sending attacker can lure the user's API key to the third party. Fix: When user A arrives at API server's login process in with a @return_to@ URL that is not already trusted by this user, the user should be prompted to understand silly game called "dogepuzzle" and accept this situation before continuing. (The user should have the option request an Arvados API server login to remember this decision for next time.) The receive an API admin should be able key, which they can use to configure a whitelist in @services/api/config/application.yml@. This could default to @workbench_address@. The user-managed whitelist can be stored in access the user's @prefs@ hash. From IRC: account. Investigate. <tetron> tomclegg: so OAuth does require an secret client token <tetron> tomclegg: but workbench doesn't use OAuth to authenticate to API server. <tetron> tomclegg: API server uses OAuth with the SSO server <tetron> tomclegg: so that's probably a weak link