Subject: [OAUTH-WG] OAuth implementation fail

From: Barry Leiba <[email-masked]>
Date: Wed, 22 Jul 2015 03:44:28 -0400

Yesterday, someone sent me a link to some presentation slides that
he'd posted to SlideShare.  I looked at them, and wanted to download
them as a PDF.  In order to let me do that, SlideShare wants me to log
in.  It gives me the options to log in via LinkedIn or Facebook.  As
I'm one of the three people in the world without a Facebook account, I
clicked "LinkedIn".  That got me an OAuth authorization screen, image
attached.

Now, I don't know if this is SlideShare's fault for asking for too
much, or LinkedIn's fault for not providing enough granularity for
requests, but just LOOK at that list of what I'd be giving SlideShare
access to.  The first few make sense: read my profile (the whole thing
or pieces of it, including contact information).  But... access to my
connections?  I'm not sure they'd like my exposing their identities to
SlideShare.  Access to my private messages?  EDIT MY PROFILE?  Srsly?

Of course, this isn't the fault of the OAuth protocol, really (though
one might argue that there's not enough guidance provided).  But,
really, with implementations like this, I have to wonder what they're
thinking.

I clicked "Cancel", of course, and asked the slide creator to send me a PDF.

Barry

---

From: Kathleen Moriarty <[email-masked]>
Date: Wed, 22 Jul 2015 03:49:09 -0400

Hey Barry,

>From my observations with Facebook, it now has options added for you to
select what resources from Facebook will get shared when authorizing access
to other applications.  You can click on each of the possibilities and
strip it down.  It appears to me that Facebook is managing that, so in your
case, I *think* (and am open to be corrected) that LinkedIn needs to do
something similar.  Without those options, I also cancel out and just don't
use the other app.

Thanks,
Kathleen

On Wed, Jul 22, 2015 at 3:44 AM, Barry Leiba <[email-masked]>
wrote:

> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>
>

-- 

Best regards,
Kathleen

---

From: Phil Hunt <[email-masked]>
Date: Wed, 22 Jul 2015 10:06:07 +0200

Interesting.  A couple of possible issues (and of course I am speculating here):

1. Using OAuth for authentication (does LinkedIn support OIDC?)
2. Not asking for the minimum information needed (either by omission or by intent)

I am really speculating now, but wonder if Slideshare didn’t actually want anything from LinkedIn, they just wanted to authenticate you. It may be that LinkedIn didn’t provide a scope and LinkedIn defaults this to “everything”. If true, this would seem to be a bad practice since it has the unintended consequence of defaulting to all scopes.

The whole process failed to convert you into a user since your experience was bad and asked for inappropriate access.  

It would be interesting to find out more of the facts around this. 

Phil

@independentid
www.independentid.com
[email-masked]

> On Jul 22, 2015, at 9:49 AM, Kathleen Moriarty <[email-masked]> wrote:
> 
> Hey Barry,
> 
> From my observations with Facebook, it now has options added for you to select what resources from Facebook will get shared when authorizing access to other applications.  You can click on each of the possibilities and strip it down.  It appears to me that Facebook is managing that, so in your case, I *think* (and am open to be corrected) that LinkedIn needs to do something similar.  Without those options, I also cancel out and just don't use the other app.  
> 
> Thanks,
> Kathleen
> 
> On Wed, Jul 22, 2015 at 3:44 AM, Barry Leiba <[email-masked] <mailto:[email-masked]>> wrote:
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
> 
> 
> 
> 
> -- 
> 
> Best regards,
> Kathleen

---

From: Justin Richer <[email-masked]>
Date: Wed, 22 Jul 2015 10:22:24 +0200

This is a pretty clear case of SlideShare trying to grab too much. The LinkedIn API (which is their own proprietary thing, not OpenID Connect) does separate all the permissions into different scopes. However, the SlideShare app is asking for all of them, and LinkedIn doesn’t let you uncheck any boxes on the authorization screen. 

FWIW, the reason they want write access to your profile is to automatically add new SlideShare presentations that you upload to your LinkedIn profile page. You should still have the option of turning that off, or of turning on that functionality later.

 — Justin

---

From: Phil Hunt <[email-masked]>
Date: Wed, 22 Jul 2015 10:26:41 +0200

Do they explicitly ask for those scopes? Or do they leave scope to default that way. 

Phil

> On Jul 22, 2015, at 10:22, Justin Richer <[email-masked]> wrote:
> 
>>> On Wed, Jul 22, 2015 at 3:44 AM, Barry Leiba <[email-masked]> wrote:

---

From: Maciej Machulak <[email-masked]>
Date: Wed, 22 Jul 2015 10:59:24 +0200

It seems that they don't ask for scopes.

The parameter is left blank: scope=

Kind regards,
Maciej

On 22 July 2015 at 10:26, Phil Hunt <[email-masked]> wrote:

> This is a pretty clear case of SlideShare trying to grab too much. The
> LinkedIn API (which is their own proprietary thing, not OpenID Connect)
> does separate all the permissions into different scopes. However, the
> SlideShare app is asking for all of them, and LinkedIn doesn’t let you
> uncheck any boxes on the authorization screen.
>
> FWIW, the reason they want write access to your profile is to
> automatically add new SlideShare presentations that you upload to your
> LinkedIn profile page. You should still have the option of turning that
> off, or of turning on that functionality later.
>
>  — Justin
>

-- 
Maciej Machulak
email: [email-masked]
mobile: +44 7999 606 767 (UK)
mobile: +48 602 45 31 66 (PL)

---

From: Justin Richer <[email-masked]>
Date: Wed, 22 Jul 2015 11:06:15 +0200

According to the LinkedIn docs, that means they get all the scopes that they registered for.

 — Justin

> On Jul 22, 2015, at 10:59 AM, Maciej Machulak <[email-masked]> wrote:
> 
> On 22 July 2015 at 10:26, Phil Hunt <[email-masked] <mailto:[email-masked]>> wrote:
> On Jul 22, 2015, at 10:22, Justin Richer <[email-masked] <mailto:[email-masked]>> wrote:
> 
>>> On Jul 22, 2015, at 9:49 AM, Kathleen Moriarty <[email-masked] <mailto:[email-masked]>> wrote:
>>> 
>>> Hey Barry,
>>> 
> email: [email-masked] <mailto:[email-masked]>

---

From: Nat Sakimura <[email-masked]>
Date: Wed, 22 Jul 2015 11:08:10 +0200

Wow, that's the very opposite of Privacy by Design/Default recommendation.

-- 
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en

---

From: John Bradley <[email-masked]>
Date: Wed, 22 Jul 2015 11:19:23 +0200

Slideshare did register all of those scopes as ones the client could ask for.

Interpreting no scopes as all the ones the client has set as the ones it wants is probably not unreasonable.

The problem is a combination of Slideshare over asking, perhaps because they don’t understand the default behaviour,  and LinkedIn now allowing only some of the scopes to be returned.

I think people are moving back to allowing people to deselect scopes.   In Android m you can now deselect scopes that apps request, both at installation and after.

One argument that people have put forward is that RP will ask for the minimum set of scopes to encourage the person to consent.   However it seems that many RP decide to grab the maximum permissions on the grounds that people agree to it.

I don’t know that any spec change is required, but perhaps some sort of education is.

If users decline all on a regular basis then the RP will be motivated to change.

John B.

> On Jul 22, 2015, at 11:08 AM, Nat Sakimura <[email-masked]> wrote:
> 
> 2015-07-22 11:06 GMT+02:00 Justin Richer <[email-masked] <mailto:[email-masked]>>:
>> On Jul 22, 2015, at 10:59 AM, Maciej Machulak <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> mobile: +44 7999 606 767 <tel:%2B44%207999%20606%20767> (UK)
> http://nat.sakimura.org/ <http://nat.sakimura.org/>
> @_nat_en

---

From: Nat Sakimura <[email-masked]>
Date: Wed, 22 Jul 2015 11:35:55 +0200

IMHO, returning everything if scope is empty is a violation of the
collection minimization principle. From the privacy by Design point of
view, a lazy programmer sending an empty request should not cause the
maximal data returned.

Now, as to the spec change is concerned, I agree with John that it is not
required.
However, a Best practice document would probably help the developers.

Nat

2015-07-22 11:19 GMT+02:00 John Bradley <[email-masked]>:

> The problem is a combination of Slideshare over asking, perhaps because
> they don’t understand the default behaviour,  and LinkedIn now allowing
> only some of the scopes to be returned.
>
> I think people are moving back to allowing people to deselect scopes.   In
> Android m you can now deselect scopes that apps request, both at
> installation and after.
>
> One argument that people have put forward is that RP will ask for the
> minimum set of scopes to encourage the person to consent.   However it
> seems that many RP decide to grab the maximum permissions on the grounds
> that people agree to it.
>

---

From: Justin Richer <[email-masked]>
Date: Wed, 22 Jul 2015 13:49:11 +0200

This may be a better fit for another article on http://oauth.net/articles/ <http://oauth.net/articles/> instead of a WG document.
 — Justin

> On Jul 22, 2015, at 11:35 AM, Nat Sakimura <[email-masked]> wrote:
> 
> IMHO, returning everything if scope is empty is a violation of the collection minimization principle. From the privacy by Design point of view, a lazy programmer sending an empty request should not cause the maximal data returned. 
> 
> Now, as to the spec change is concerned, I agree with John that it is not required. 
> 2015-07-22 11:19 GMT+02:00 John Bradley <[email-masked] <mailto:[email-masked]>>:
>> On Jul 22, 2015, at 11:08 AM, Nat Sakimura <[email-masked] <mailto:[email-masked]>> wrote:
>>

---

From: Phil Hunt <[email-masked]>
Date: Wed, 22 Jul 2015 13:52:48 +0200

Agreed.

I have heard it can be equally bad to pester the user every time a new scope is needed.

There’s a definite balancing problem.

I don’t think this an OAuth issue; just a good user experience issue.

Phil

@independentid
www.independentid.com
[email-masked]

---

From: Nat Sakimura <[email-masked]>
Date: Wed, 22 Jul 2015 14:50:38 +0200

I think it would be good to have both a guideline informative RFC as well
as the oauth.net blog entry, former being more "formal" in the way of
writing while the later can be more readable one.

Re: pestering factor -- Indeed, I am the one started to talk about "turning
an internet dog into a Pavlov's dog" and agree that pestering the user too
much is not good. As in EU DP Directive and forthcoming regulation, we
should actually skip the dialogue if it falls into one of the "conditions
for processing" (apart from the explicit consent condition).

However, if it is asking something that is not required for the immediate
processing, it should ask, and the user should be alerted that something
fishy is happening.

I am working on these notice and consent issues at ISO/IEC JTC 1/SC 27/WG 5
so if you are interested, please do join :-)

Nat

2015-07-22 13:52 GMT+02:00 Phil Hunt <[email-masked]>:

>> I think people are moving back to allowing people to deselect scopes.
>> In Android m you can now deselect scopes that apps request, both at
>> installation and after.
>>

---

From: William Denniss <[email-masked]>
Date: Wed, 22 Jul 2015 15:01:24 +0200

On the pestering topic, one way that can be avoided is by using incremental
auth to ask for permissions just-in-time. That pattern holds up when new
scopes are required for new features.  By contextualising the permission
ask, it likely leads to higher conversion rates as users can figure out why
the information is being requested, and by being optional the cost of
denying the permissions is not so great (unlike when sign is prevented
through user rejection).

Permission screens that ask for the kitchen sink just to sign you in are
the death of identity federation.

On Wed, Jul 22, 2015 at 2:50 PM, Nat Sakimura <[email-masked]> wrote:

> Re: pestering factor -- Indeed, I am the one started to talk about
> "turning an internet dog into a Pavlov's dog" and agree that pestering the
> user too much is not good. As in EU DP Directive and forthcoming
> regulation, we should actually skip the dialogue if it falls into one of
> the "conditions for processing" (apart from the explicit consent
> condition).
>
> I am working on these notice and consent issues at ISO/IEC JTC 1/SC 27/WG
> 5 so if you are interested, please do join :-)
>
> Nat
>
>>>>> From my observations with Facebook, it now has options added for you
>>>>> to select what resources from Facebook will get shared when authorizing
>>>>> access to other applications.  You can click on each of the possibilities
>>>>> and strip it down.  It appears to me that Facebook is managing that, so in
>>>>> your case, I *think* (and am open to be corrected) that LinkedIn needs to
>>>>> do something similar.  Without those options, I also cancel out and just
>>>>> don't use the other app.
>>>>>
>>>>> Thanks,
>>>>> Kathleen
>>>>>

---

From: Nat Sakimura <[email-masked]>
Date: Wed, 22 Jul 2015 15:05:12 +0200

+1

Is there any A/B test kind of statistics on the improvement of the
conversion of the incremental authz over kitchen sink authz?
If there is, it would be a very good data to show to those people who want
everything upfront.

Nat

2015-07-22 15:01 GMT+02:00 William Denniss <[email-masked]>:

> On the pestering topic, one way that can be avoided is by using
> incremental auth to ask for permissions just-in-time. That pattern holds up
> when new scopes are required for new features.  By contextualising the
> permission ask, it likely leads to higher conversion rates as users can
> figure out why the information is being requested, and by being optional
> the cost of denying the permissions is not so great (unlike when sign is
> prevented through user rejection).
>
>>>>>> This is a pretty clear case of SlideShare trying to grab too much.
>>>>>> The LinkedIn API (which is their own proprietary thing, not OpenID Connect)
>>>>>> On Wed, Jul 22, 2015 at 3:44 AM, Barry Leiba <[email-masked]
>>>>>> > wrote:
>>>>>>

---

From: Barry Leiba <[email-masked]>
Date: Thu, 23 Jul 2015 07:03:53 -0400

> However, a Best practice document would probably help the developers.

That's exactly what I had in mind -- no spec change, but something (or
some things) to help guide developers into do the right thing,
security-wise and user-experience-wise.

Thanks, everyone, for discussing this.

Barry