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:
So, wrt FB, signed request is good. It can be another example to add.
On Sun, Nov 2, 2014 at 19:55 Phil Hunt <phil.h...@oracle.com
<mailto:phil.h...@oracle.com>> wrote:
Sigh.
Phil
@independentid
www.independentid.com <http://www.independentid.com>
phil.h...@oracle.com <mailto:phil.h...@oracle.com>
On Nov 2, 2014, at 10:33 AM, John Bradley <ve7...@ve7jtb.com
<mailto:ve7...@ve7jtb.com>> 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 <phil.h...@oracle.com
<mailto:phil.h...@oracle.com>> wrote:
>
>> 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
<tors...@lodderstedt.net <mailto:tors...@lodderstedt.net>> wrote:
>>>
>>> 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 <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
<hannes.tschofe...@gmx.net <mailto:hannes.tschofe...@gmx.net>> 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 <http://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
>>>>> OAuth@ietf.org <mailto:OAuth@ietf.org>
>>>>> https://www.ietf.org/mailman/__listinfo/oauth
<https://www.ietf.org/mailman/listinfo/oauth>
>>>> _________________________________________________
>>>> OAuth mailing list
>>>> OAuth@ietf.org <mailto:OAuth@ietf.org>
>>>> https://www.ietf.org/mailman/__listinfo/oauth
<https://www.ietf.org/mailman/listinfo/oauth>
>>>
>>> _________________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org <mailto:OAuth@ietf.org>
>>> https://www.ietf.org/mailman/__listinfo/oauth
<https://www.ietf.org/mailman/listinfo/oauth>
>>
>> _________________________________________________
>> OAuth mailing list
>> OAuth@ietf.org <mailto:OAuth@ietf.org>
>> https://www.ietf.org/mailman/__listinfo/oauth
<https://www.ietf.org/mailman/listinfo/oauth>
>
_________________________________________________
OAuth mailing list
OAuth@ietf.org <mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/__listinfo/oauth
<https://www.ietf.org/mailman/listinfo/oauth>
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--
Hans Zandbelt | Sr. Technical Architect
hzandb...@pingidentity.com | Ping Identity
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
