I agree with the considerations, but I also feel that they are generally
true for 3rd party clients to services where the resource owner has an
account/profile.
1. typically the case for a /me (read) profile API
2. best practice after earlier exploits
3. the "code" has a recommended lifetime of 10 minutes by spec
I also agree that because there are a number of conditions that need to
be met (even though generally true as Phil says) as such it may be wise
not to spell out this scenario with the risk of becoming "best" practice.
I am not really advocating for this anyway, it just struck me that
authz/authn really overlap here (admittedly as a "special" case).
Hans.
On 10/20/14, 11:22 PM, John Bradley wrote:
Even in the simple code use case there are things that need to be profiled.
1. The resource owner must be the only one who can grant AT for the profile
resource. (This may not be true for general purpose API or require a special
api call)
2. OAuth allows a fair flexibility around redirect uri matching with confidential
clients. "code" can be intercepted and replayed to the client. The
redirect_uri matching rules need to be tightened up like Connect has done. Oauth
assumes that a third party can't use code to get to the protected resource because of the
client secret, for an identity service replaying code to the client is an attack.
(Oauth mitigates this by sending the redirect_uri in the request to the token
endpoint, but exact matching of that URI including query parameters is not
necessarily treated with sufficient diligence by implementations only thinking
about authorization.
3. There is no real authentication context so the clieent has no idea when the
user authenticated or how etc.
There are probably other things but re-using an existing data API for
authentication may go seriously wrong even in this case without a fairly
sophisticated analysis.
John B.
On Oct 20, 2014, at 5:06 PM, Phil Hunt <phil.h...@oracle.com> wrote:
The problem is you are making a lot of assumptions that may or may not be true
- they are just generally true.
The right to access may be granted without even authenticating a user. For
example, a web resource might allow any registered client to have acess to any
resource. Only certain scopes require consent. For example, readProfile is
public, but updateProfile is restricted.
The presumption that receiving an AT would be entirely false in this situation
as the user was never even authenticated because consent was not required.
We’ve also talked about how access to a resource /Me also binds the name of the
authenticate user to the access request. If the API does not have a /Me
endpoint, than the identity information you are requesting could be for any
person the AT is allowed to see. This creates another “hack” point where
clients could be fooled to thinking they have authenticate a particular person
when in fact all they have proven is access it a particular resource not
necessarily the user is valid.
Phil
@independentid
www.independentid.com
phil.h...@oracle.com
On Oct 20, 2014, at 12:29 PM, Richer, Justin P. <jric...@mitre.org> wrote:
Right, when you get the AT directly from the token endpoint and it's good for something,
that will *probably* tell you the user is logged in. This is assuming that the
authentication context can also be communicated, audience restrictions can be
communicated, and all the other good stuff the document talks about. A real problem tends
to stem from clients who will take access tokens from various public endpoints and use
them directly (implicit clients are inherently open to this problem). Or that an access
token can have a life long past the authentication event, so if a client saves the access
token off someplace, does a bunch of work, then finally asks "Who's there?" and
makes the user info API call, it's going to get info but not necessarily what it assumes.
Really, all of this is why there's the ID Token and the Signed Request
components in OIDC and FBC, respectively. Plus you don't always want the
profile information on every request, so having something the client can read
directly saves a round trip to fetch data it doesn't really want. Having the
separation between the authentication context and the profile information
really does make the code paths a bit simpler.
-- Justin
On Oct 20, 2014, at 3:20 PM, Hans Zandbelt <hzandb...@pingidentity.com> wrote:
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
_______________________________________________
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
--
Hans Zandbelt | Sr. Technical Architect
hzandb...@pingidentity.com | Ping Identity
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
