Subject: Re: [OAUTH-WG] Notes from 2nd "OAuth & Authentication" Conference Call

From: Torsten Lodderstedt <[email-masked]>
Date: Sun, 02 Nov 2014 18:04:12 +0100

Hi all,

I just read the document. It explains the situation, challenges/threats, 
and options very clear and readable.

So +1 for publishing it soon.

kind regards,
Torsten.

Am 28.10.2014 00:21, schrieb Richer, Justin P.:
> I've been incorporating peoples' feedback into the proposed oauth.net page, and the current state is here:
>
> https://github.com/jricher/oauth.net/blob/authentication/articles/authentication.php
>
> Commentary has slowed down and I think the document's in reasonable. I would like to publish this as a draft version on oauth.net in the very near future (like, this week), so get comments and feedback to me on this soon. I'm going to be at IIW all week if anyone wants to back me into a corner and talk about this.
>
>   -- Justin
>
> On Oct 16, 2014, at 12:54 PM, Hannes Tschofenig <[email-masked]> wrote:
>
>> Participants:
>>
>> * Brian Campbell
>> * John Bradley
>> * Derek Atkins
>> * Phil Hunt
>> * William Kim
>> * Josh Mandel
>> * Hannes Tschofenig
>>
>>
>> Notes:
>>
>> Justin distributed a draft writeup and explained the reasoning behind
>> it. The intended purpose is to put the write-up (after enough review) on
>> oauth.net. See attachments. Justin solicited feedback from the
>> conference call participants and from the working group.
>>
>> One discussion item was specifically related to the concept of audience
>> restrictions, which comes in two flavours: (a) restriction of the access
>> token regarding the resource server and (b) restriction of the id token
>> regarding the client. Obviously, it is necessary to have both of these
>> audience restrictions in place and to actually check them.
>>
>> The group then went into a discussion about the use of pseudonyms in
>> authentication and the problems deployments ran into when they used
>> pseudonyms together with a wide range of attributes that identified
>> users nevertheless. Phil suggested to produce a write-up about this topic.
>>
>> Finally, the group started a discussion about potential actions for the
>> OAuth working groups. Two activities were mentioned, namely to produce
>> an IETF draft of the write-up Justin has prepared as a "formal" response
>> to the problems with authentication using OAuth and, as a second topic,
>> potential re-chartering of the OAuth working group to work on some
>> solutions in this area. Hannes suggested to postpone these discussions
>> and to first finish the write-up Justin had distributed.
>>
>> Ciao
>> Hannes & Derek
>> <Authentication with OAuth 2.doc><Authentication with OAuth 2.html><Authentication with OAuth 2.pdf>_______________________________________________
>> OAuth mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/oauth
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: Phil Hunt <[email-masked]>
Date: Sun, 2 Nov 2014 09:15:42 -0800

We may have a problem with audience here. 

Justin mentioned he wrote it for service providers but the threats are against the client that wants to authenticate users. 

Would be better to have recommendations for each group. 

Since oidc is the only recommendation, what does a client implementer do when openid connect is not available?  Suggest we give a list of qualities developers should look for (eg is fb connect good)?

Phil

> On Nov 2, 2014, at 09:04, Torsten Lodderstedt <[email-masked]> wrote:
> 
> Hi all,
> 
> I just read the document. It explains the situation, challenges/threats, and options very clear and readable.
>

---

From: John Bradley <[email-masked]>
Date: Sun, 2 Nov 2014 15:33:38 -0300

If a client developer doesn't have Connect available then they need to point the API developer at this doc, so that they do provide Connect or some other API that takes into account all of the security considerations.

A client developer should never make up there own identity protocol out of someone else's API that is not designed for it.

A vanilla OAuth API with no additional security considerations on the API developers part is pretty much guaranteed to go horribly wrong.

John B.

---

From: Phil Hunt <[email-masked]>
Date: Sun, 2 Nov 2014 11:55:06 -0800

Sigh.

Phil

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

---

From: Nat Sakimura <[email-masked]>
Date: Sun, 02 Nov 2014 20:16:57 +0000

So, wrt FB, signed request is good. It can be another example to add.
On Sun, Nov 2, 2014 at 19:55 Phil Hunt <[email-masked]> wrote:

> > If a client developer doesn't have Connect available then they need to
> point the API developer at this doc, so that they do provide Connect or
> some other API that takes into account all of the security considerations.
> >
> > A client developer should never make up there own identity protocol out
> of someone else's API that is not designed for it.
> >
> > A vanilla OAuth API with no additional security considerations on the
> API developers part is pretty much guaranteed to go horribly wrong.
> >
> > John B.
> >
> >> Justin mentioned he wrote it for service providers but the threats are
> against the client that wants to authenticate users.
> >>
> >> Since oidc is the only recommendation, what does a client implementer
> do when openid connect is not available?  Suggest we give a list of
> qualities developers should look for (eg is fb connect good)?
> >>
> >> Phil
> >>
> >>> I just read the document. It explains the situation,
> challenges/threats, and options very clear and readable.
> >>>
> >>>> Commentary has slowed down and I think the document's in reasonable.
> I would like to publish this as a draft version on oauth.net in the very
> near future (like, this week), so get comments and feedback to me on this
> soon. I'm going to be at IIW all week if anyone wants to back me into a
> corner and talk about this.
> >>>>
> >>>> -- Justin
> >>>>
> >>>>> <Authentication with OAuth 2.doc><Authentication with OAuth
> 2.html><Authentication with OAuth 2.pdf>________________________
> _______________________
> >>>>> OAuth mailing list
> >>>>> [email-masked]

---

From: John Bradley <[email-masked]>
Date: Sun, 2 Nov 2014 17:53:36 -0300

Your proposal required changes and extensions to the AS.

Without some cooperation from the AS /API provider, they shouldn't be using OAuth for identity.

The client can't make it secure all on it's own.   The API semantics might change,  the client would largely be relying on luck.

Sorry,

What sort of advice are you looking for that the client can implement without the cooperation of the IdP around some of the security considerations.
About the only thing would be to never use implicit.  However that alone in my opinion is not sufficient for real security.

John B.

---

From: Phil Hunt <[email-masked]>
Date: Sun, 2 Nov 2014 13:47:51 -0800

That is not what I said. 

I said establish the criteria for mitigation of the threats. 

Phil

> On Nov 2, 2014, at 12:53, John Bradley <[email-masked]> wrote:
>

---

From: John Bradley <[email-masked]>
Date: Sun, 2 Nov 2014 20:14:22 -0300

Many of the threats can only be mitigated by the AS/IDP .   This document should cover that.   

I didn't say the IdP must use connect only that it needs to understand and mitigate the treats from the document,  implementing Connect is one way to do it.

Sorry I was trying to interpret "Sigh"

John B.

---

From: John Bradley <[email-masked]>
Date: Sun, 2 Nov 2014 20:20:55 -0300

Some old posts on designing a single sign-on system with OAuth 2.

They may not have been in the ones I sent to Justin.
http://www.thread-safe.com/2012/02/designing-single-sign-on-system-using.html
http://www.cloudidentity.com/blog/2013/01/02/oauth-2-0-and-sign-in-4/

Are you wanting something more like these with the info on how you could do it with OAuth 2?

John B.

---

From: Phil Hunt <[email-masked]>
Date: Sun, 2 Nov 2014 15:52:27 -0800

John

I am trying to establish how a client app org should assess an AS org and their approach. 

Why is fb/connect or oidc, or other approaches good or bad?

The client org has to do this. We shouldn't be in the business of assessing goodness or compliance. 

Phil

> On Nov 2, 2014, at 15:14, John Bradley <[email-masked]> wrote:
>

---

From: "Richer, Justin P." <[email-masked]>
Date: Mon, 3 Nov 2014 00:30:15 +0000

Phil,

When you write that article, just let me know and I'll add a link to it from this one.

Thanks,
 -- Justin

---

From: Hans Zandbelt <[email-masked]>
Date: Mon, 03 Nov 2014 10:55:04 +0100

Facebook also has a "code" flow that uses a introspection call that is 
precisely an example of the OAuth 2.0 + a-bit-of-luck type of login that 
I was asking about earlier in this thread:

https://developers.facebook.com/docs/facebook-login/manually-build-a-login-flow/v2.2

Hans.

On 11/2/14, 9:16 PM, Nat Sakimura wrote:
> On Sun, Nov 2, 2014 at 19:55 Phil Hunt <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     Sigh.
>
>     Phil
>
>     @independentid
>     www.independentid.com <http://www.independentid.com>
>     [email-masked] <mailto:[email-masked]>
>
>
>
>     On Nov 2, 2014, at 10:33 AM, John Bradley <[email-masked]
>     <mailto:[email-masked]>> wrote:
>
>      > If a client developer doesn't have Connect available then they
>     need to point the API developer at this doc, so that they do provide
>     Connect or some other API that takes into account all of the
>     security considerations.
>      >
>      > A client developer should never make up there own identity
>     protocol out of someone else's API that is not designed for it.
>      >
>      > A vanilla OAuth API with no additional security considerations on
>     the API developers part is pretty much guaranteed to go horribly wrong.
>      >
>      > John B.
>      >
>      > On Nov 2, 2014, at 2:15 PM, Phil Hunt <[email-masked]
>     <mailto:[email-masked]>> wrote:
>      >
>      >> Justin mentioned he wrote it for service providers but the
>     threats are against the client that wants to authenticate users.
>      >>
>      >> Since oidc is the only recommendation, what does a client
>     implementer do when openid connect is not available?  Suggest we
>     give a list of qualities developers should look for (eg is fb
>     connect good)?
>      >>
>      >> Phil
>      >>
>      >>> On Nov 2, 2014, at 09:04, Torsten Lodderstedt
>     <[email-masked] <mailto:[email-masked]>> wrote:
>      >>>
>      >>> Hi all,
>      >>>
>      >>>> I've been incorporating peoples' feedback into the proposed
>     oauth.net <http://oauth.net> page, and the current state is here:
>      >>>>
>      >>>>
>     https://github.com/jricher/__oauth.net/blob/authentication/__articles/authentication.php
>     <https://github.com/jricher/oauth.net/blob/authentication/articles/authentication.php>
>      >>>>
>      >>>> Commentary has slowed down and I think the document's in
>     reasonable. I would like to publish this as a draft version on
>     oauth.net <http://oauth.net> in the very near future (like, this
>     week), so get comments and feedback to me on this soon. I'm going to
>     be at IIW all week if anyone wants to back me into a corner and talk
>     about this.
>      >>>>
>      >>>> -- Justin
>      >>>>
>      >>>>> On Oct 16, 2014, at 12:54 PM, Hannes Tschofenig
>     <[email-masked] <mailto:[email-masked]>> wrote:
>      >>>>>
>      >>>>> Participants:
>      >>>>>
>      >>>>> * Brian Campbell
>      >>>>> * John Bradley
>      >>>>> * Derek Atkins
>      >>>>> * Phil Hunt
>      >>>>> * William Kim
>      >>>>> * Josh Mandel
>      >>>>> * Hannes Tschofenig
>      >>>>>
>      >>>>>
>      >>>>> Notes:
>      >>>>>
>      >>>>> oauth.net <http://oauth.net>. See attachments. Justin
>     solicited feedback from the
>     2.html><Authentication with OAuth
>     2.pdf>_________________________________________________
>      >>>>> OAuth mailing list
>      >>>>> [email-masked] <mailto:[email-masked]>
>      >>>>> https://www.ietf.org/mailman/__listinfo/oauth
>     <https://www.ietf.org/mailman/listinfo/oauth>
>      >>>> _________________________________________________
>      >>>> OAuth mailing list
>      >>>> [email-masked] <mailto:[email-masked]>
>      >>>> https://www.ietf.org/mailman/__listinfo/oauth
>     <https://www.ietf.org/mailman/listinfo/oauth>
>      >>>
>      >>> _________________________________________________
>      >>> OAuth mailing list
>      >>> [email-masked] <mailto:[email-masked]>
>      >>> https://www.ietf.org/mailman/__listinfo/oauth
>     <https://www.ietf.org/mailman/listinfo/oauth>
>      >>
>      >> _________________________________________________
>      >> OAuth mailing list
>      >> [email-masked] <mailto:[email-masked]>
>      >> https://www.ietf.org/mailman/__listinfo/oauth
>     <https://www.ietf.org/mailman/listinfo/oauth>
>      >
>
>     _________________________________________________
>     OAuth mailing list
>     [email-masked] <mailto:[email-masked]>
>     https://www.ietf.org/mailman/__listinfo/oauth
>     <https://www.ietf.org/mailman/listinfo/oauth>
>
>
>

-- 
Hans Zandbelt              | Sr. Technical Architect
[email-masked] | Ping Identity