What to do on an OAuth Permission page
From IIW
Yahoo Learnings:
- Tell users 3rd party is not affiliated with SP, because users blindly trust SP to do the right thing. e.g. "this app is not made by yahoo". Someone commented that the Apps Engine Openid IDP app was confusing, as they weren't sure whether Google was officially an openid provider
- Tell users that if they don't trust app, don't allow access. Denying access isn't a bad thing.
- Range of data and type of access is useful to explain carefully. E.g. Users think "delete" and "write" are different things when they see read vs write access. Some text they've adopted: "Yahoo Profile to read your public profile data and your connections", "Yahoo mail to read, write, and delete your email"
- Explain duration of access
- Describe how to revoke
- Showing application name and short description are useful
- Tell user that 3rd party does not have access to password
- Maybe: "don't enter your password on the next page"
Other Questions / Comments
- How do you protect against phishing?
- Stats - after making the above changes to Yahoo OAuth, it would be interesting to check if more people decline vs BBAuth flow.
- What about UX on consumer side? How do users know they are going through OAuth, a process that doesn't require passwords?
- OAuth is great, but we lack common data formats
- OAuth was designed without "level of access" in mind. It was for use cases such as "allow this app to upload photos to my account," and not use cases such as "only share these contacts to this app."
-- Vince Wu, Google Inc
