My point is that it *is* a guarantee if the AT just came to the client
in a code flow; I don't see a problem with that although clients have to
be aware of what they're doing and not allow any other flows for this.
Hans.
On 10/20/14, 9:04 PM, Richer, Justin P. wrote:
This is actually one of the sticky bits that I've tried to address in the
document itself -- I've seen apps that assume that if they're given an access
token that can be used to fetch profile information then the user is actually
there. This isn't actually a guarantee, but it's commonly true enough that
developers get lazy and rely on it.
-- Justin
On Oct 20, 2014, at 2:42 PM, Hans Zandbelt <hzandb...@pingidentity.com> wrote:
or pointier: there are OAuth 2.0 deployments today that offer login semantics
because they have a REST/JSON user profile API that can be accessed using the
AT that was obtained in a code flow; should that be acknowledged in the doc?
Hans.
On 10/16/14, 11:23 PM, Hans Zandbelt wrote:
a deployment-related question that I have around this topic:
it seems that authentication using OAuth 2.0 is possible today for
confidential clients using the code flow, with a registered
redirect_uri, not consuming/storing/using refresh_tokens, and assuming
that there's an API that returns user identity info in JSON format and
the claim that uniquely identifies the user is known by the client.
The usage/presence of the short-lived code in this scenario/flow
guarantees that the user has just authenticated, and the audience issue
is covered by the fact that the code (thus the access_token in the token
endpoint response) are bound to the confidential client, all as per
standard OAuth 2.0 semantics.
2 questions about that:
- is this right or am I overlooking some security/semantics issues here
- if right, would it make sense to acknowledge that or is that muddying
the waters even more (the current text does seem to only implicitly
acknowledge this)
There may be value in acknowledging this because the majority of OAuth
2.0 OPs exposing a userinfo-like API would adhere to a REST GET+JSON
response anyhow [1] thus achieving login semantics with plain OAuth 2.0
and a bit of common practice wrt. the user info API.
Thanks for the excellent write-up!
Hans.
PS: I've been asked this concrete question about Spotify's OAuth 2.0
support and in fact I'm able to configure Spotify as an IDP to my OIDC
client with a minor workaround to abstain from expecting an id_token in
the token endpoint response, but calling the Spotify specific user info
endpoint like it was a standards-compliant OpenID Connect endpoint. (the
client has a per-OP configurable unique user id claim name anyhow).
On 10/16/14, 7:27 PM, Richer, Justin P. wrote:
Ah yes, good catch! If only someone would put up a webpage describing
the difference between authorization and authentication and why people
need to stop confusing the two.
Oh wait...
On Oct 16, 2014, at 1:06 PM, Hans Zandbelt
<hzandb...@pingidentity.com> wrote:
About the write-up: at the end of the metaphor section it says:
"These recipes each add a number of items, such as a common profile
API, to OAuth to create an authorization protocol."
whereas I believe that should read "to create an authentication
protocol"
Hans.
On 10/16/14, 6:54 PM, 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
--
Hans Zandbelt | Sr. Technical Architect
hzandb...@pingidentity.com | Ping Identity
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--
Hans Zandbelt | Sr. Technical Architect
hzandb...@pingidentity.com | Ping Identity
--
Hans Zandbelt | Sr. Technical Architect
hzandb...@pingidentity.com | Ping Identity
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
