+1. I'm finding this write-up summarizing the "OAuth2 and
Authentication" 'situation' perfectly. It does help.
Minor suggestions/questions:
- might make sense to point out that an id_token can be linked to the
access token (via at_hash), thus confirming both tokens came from the
same AS
- should a 2-way TLS mentioned as a possible approach for mitigating the
'injection of the token' attack ? I guess it won't scale really well but
IMHO it is a useful mechanism nonetheless
- should a few words be reserved for the client credentials flow - this
is of course not a mainstream OAuth2 nor its related to OIDC but it is
all about the authentication IMHO, the clients get their tokens by
simply getting authenticated, and as far as legacy (code) clients are
concerned they 'migrate' from sending the name/password to the resource
endpoint on every request ?
- IMHO it would be useful to mention that OIDC RP can help non-OAuth2
servers, i.e one does not have to write an OAuth2 client web application
to get the benefits of the OIDC-driven auhentication
Thanks, Sergey
On 16/10/14 17:54, Hannes Tschofenig 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
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
