Hi,
On 17/10/14 14:33, Richer, Justin P. wrote:
On Oct 17, 2014, at 8:25 AM, Sergey Beryozkin <sberyoz...@gmail.com> wrote:
+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
Seems a reasonable point, I can add that.
- 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
It doesn't actually help in this case, since if the client is checking the
server's certs that should be OK (or as OK as TLS can get). The real attack
comes from someone handing the token to an application through a mechanism
other than the return from the token endpoint, and I've seen a handful of
applications that pass around the access token to themselves through internal
callback mechanisms that are a bit more exposed than they ought to be.
OK, I understand
- 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 ?
The client credentials flow has nothing to do with user authentication, which
is why it's left out of OIDC. There might not even be a user in this flow (and
it's generally assumed that there isn't).
Yes, it is not part of OIDC but it is still the authentication of the
client that is effectively a resource owner, no human user is involved
but IMHO it's still very much the authentication. Exactly what the coded
clients do today in non OAuth2 client-server communications, except that
in this case the name/password is offered only once to AS.
May be it was not what this flow was envisaged for originally but I do
like it for the reasons outlined above, specifically it can help the
legacy/traditional clients to 'join' the OAuth2 AS infrastucture
- 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 authentication
I don't understand what you're saying here. In order to make an OIDC RP, you
need to write an OAuth2 client. That's by design.
OIDC RP is a client. But this RP doe snot have to be collocated with the
OAuth2 client which actually does some application specific work, right ?
I.e OIDC RP facilitates the OAuth2-based authentication mechanism but
the server 'protected' by this RP which would work with the
authenticated user does not have to be OAuth2 client, do you agree ?
If OIDC RP could only be used alongside OAuth2 clients then it would
limit its usefulness IMHO
Cheers, Sergey
-- Justin
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
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
