Hi
On 17/10/14 16:13, John Bradley wrote:
Are you saying that the OIDC filter/client can set session cookies in a domain
that other web servers can use, so they don't have to have any direct knowledge
of Connect.
Yes. It is a pity I was not able to express myself with a single
sentence like you offered above :-)
I suspect that is a common practice in many SSO implementations. It is true
that not every web server needs to implement connect itself for SSO.
Right; I guess it would make sense to make it a bit more obvious in some
docs, may be in Opend id Connect Intro or similar
Thanks, Sergey
John B.
On Oct 17, 2014, at 11: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
- 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 ?
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
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
