Hi,
On 17/10/14 16:11, Richer, Justin P. wrote:
On Oct 17, 2014, at 10:57 AM, Sergey Beryozkin <sberyoz...@gmail.com> wrote:
Hi,
On 17/10/14 15:09, Richer, Justin P. wrote:
- 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 infrastructure
But it's not authentication of the *user*, which is the whole point. When the client
authenticates on its own behalf, you have no idea who the user is or if they exist. It's
irrelevant to the user authentication flow. If you're looking for pulling legacy clients
in, the "password" flow is better for that, but OIDC didn't profile it because
people really shouldn't be using the password flow except in very limited use cases in
the first place.
I did get that. See the notes are about "OAuth2 & Authentication", so I thought
it would not only be about the human user being authenticated via OIDC.
OAuth2 has different flows with some of them requiring no human user being
around, and the client_credentials flow is all about authenticating the client
giving the token back for it to access its own resources, except that not
having to sent name/password every time.
This client does not need to be aware of any users because effectively this
client is a 'user'.
If "OAuth2 & Authentication" implies the human user is involved then may be it
would be clearer if the subject was reworded somehow...
Either way, if you reckon the client-credentials are out of scope then I'm fine
with that, I guess keeping it focused on OIDC will help with the message
Interesting, that's a misinterpretation that I didn't anticipate. I think I'm going to
rename the whole page "OAuth and User Authentication" to avoid that.
To be clear, the notes did not confuse me :-), it is obvious they are
about having the user involved in the authorization code/implicit flows
involved, I just thought may be the doc can be enhanced further to cover
various OAuth2 situations where the 'authentication' is involved.
Yea, "OAuth2 and User Authentication" is a good subject name IMHO
- 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
But the OIDC RP *is* an OAuth Client, so I still don't get what you're saying.
Sure you can have OAuth clients that *aren't* OIDC clients, but you can't have
an OIDC client that isn't also an OAuth client because OIDC is built directly
on top of OAuth.
May be it is my language issues. I haven't suggested that OIDC can be
implemented without it being OAuth2 client.
Consider this:
OIDC RP filter <-> non OAuth2 server
OIDC RP filter would do the OIDC thing (will act as OAuth2 client, return the
user to OIDC IDP, validate the response) and then set the security context and
let the user go to the non OAuth2 (client) server, with this server not being
even aware that the OIDC flow has happened.
Am not making sense at all with the above ?
I think I see what you're saying now -- you could have a client that
authenticates the user through OIDC and also accesses some set of non-identity
APIs through OAuth, and the two parts don't actually have to talk to each
other. That's fine, but it's such a deep implementation detail that I don't
think it helps the conversation that we're trying to have. Especially
considering that the real problem stems from developers who do both
authentication and authorized API access right side by side in the same code
and get the two confused with each other. Is that a bit more clear?
Not quite :-), actually, this is a good point about the OIDC filter
being possibly separate from the 'actual' OAuth2 client web app
expecting an authenticated user, as it happens I'm wondering right now
how I can get it implemented so that a boilerplate client code stays
clear of dealing with authenticating the user.
But you are right, I do refer to a case of the OIDC filter/RP being
'separate' except that for the purpose of this discussion I'm referring
to a case where it protects a non OAuth2 server, i.e, the server which
does not know what OAuth2 is. That is, I think OIDC RPs can be used to
protect all types of servers, some of them will be OAuth2 clients on
their own, some of them will be web apps which do not do OAuth2 at all.
Perhaps it is off-topic for the actual notes, might deserve some note
elsewhere...
When I go to the OIDC site, I see it talks about the evolution from
OpenId 2.0. The latter could have been used to log in users into non
OAuth2 servers. The OAuth2-centricity of OIDC is its 'implementation
detail'. But when I read about it it's all only about OAuth2 which is
fair enough, OIDC is perfectly aligned with OAuth2, but if we have
developers who have written non-OAuth2 servers protected by 'legacy'
IDPs then they should know they won't have to turn their non-OAuth2
servers into OAuth2 client web apps to have the authentication supported
by OIDC - a non collocated OIDC RP would help them to migrate to OIDC
with their non-OAuth2 servers continuing doing whatever they do unchanged.
Sorry I may've lost everyone with my reasoning above :-)
Many thanks
Sergey
Thanks for your input,
-- Justin
Thanks, Sergey
-- Justin
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
