Igor,
The question is not whether to remove the parameter from the spec, but
rather what one would expect as a "default" behavior from a "normal"
OAuth2 provider. Option1 says that the default is to leave it out of the
response. But it'll still be there in cases where the AS and PR know
what the value means.
-- Justin
On 01/10/2013 12:08 PM, Igor Faynberg wrote:
I chime in in support of option 1. Rationale: nothing is worse
than the presence of an obscure parameter. (Not only it pollutes the
environment, but it is a potential attack vector.) So rather than
invent an acceptable value for it, I would remove it.
Igor
On 1/10/2013 11:59 AM, George Fletcher wrote:
That makes sense as well:)
Hopefully some others will chime in as I think this is an area that
could use some "best practice" guidelines.
Thanks,
George
On 1/10/13 11:53 AM, Justin Richer wrote:
I'm leaning towards 1 because the client is more the "authorized
presenter" of the token, not its audience.
-- Justin
On 01/10/2013 11:52 AM, George Fletcher wrote:
So in the default case I see two options for an AS that wants to
implement this endpoint...
1. Omit 'audience' from the response: The rationale here is that
there really isn't an explicit audience and what clients need to
protect against things like "confused deputy" is the client_id
which is already one of the response fields.
2. Make the 'audience' value the same as the 'client_id' value: The
rationale here is that the "audience" of the token is the entity
for which the token was minted which in the default OAuth2 case is
the client_id.
Any thoughts as to which is the best option? For now I'm going with
option 2.
Thanks,
George
On 1/10/13 9:18 AM, Justin Richer wrote:
In traditional OAuth, there really isn't a baked-in notion of
'audience' since the AS<->PR connection is completely out of
scope. However, in practice, when you've got more than one PR per
AS, you'll have some notion of 'audience'. It's definitely
possible to handle this with 'scope', especially if you want the
client to have a say in the matter. But since you could have your
scopes and audiences defined independently (one scope across
several audiences, one audience with many scopes, and any other
combination thereof) I think it makes sense to at least define a
place for the AS to express this back to the PR. JWT has the exact
same claim for the exact same reason.
As George points out below, this also really comes into play in
the chaining case, where you've got one PR calling another PR and
you need to keep things straight in a large backend.
So while I agree it'd be better if OAuth had an 'audience' concept
all the way through, I don't think it should be precluded from the
introspection response just because it doesn't.
-- Justin
On 01/09/2013 04:47 PM, George Fletcher wrote:
I had the same confusion about "what is 'audience' in OAuth?"
today working on a completely different project.
I think for the default OAuth2 deployment, scopes take the place
of audience because the scopes identify the authorization
grant(s) at the resource servers affiliated with the
Authorization Server. The client can present the token to any
resource server and if the necessary authorization grant(s) are
present, the protected resource is returned. The client doesn't
have to explicitly call out that it is going to present the token
to the 'mail service', it just needs to ask for the 'readMail' scope.
So, in regards to an AS implementation of the introspection
endpoint, what are the expectations for how the AS fills in the
'audience' field. Should the AS not return the field if there is
no audience? Should the AS return "itself" as the audience? If a
token has scopes of 'readMail writeMail readBuddyList sendIM'
then what is the correct 'audience' of the token? Should it be an
array of the resource servers that depend on those scopes?
I can see value in the chaining scenario of a client asking the
AS for a token that it will give to another party to present and
storing that intermediate party in the token. But for the default
OAuth2 case, should audience be omitted? or be the same value as
'client_id'?
Thanks,
George
On 1/9/13 3:15 PM, Richer, Justin P. wrote:
On Jan 9, 2013, at 3:05 PM, Torsten Lodderstedt
<tors...@lodderstedt.net <mailto:tors...@lodderstedt.net>> wrote:
Hi Justin,
Am 09.01.2013 um 20:35 schrieb Justin Richer <jric...@mitre.org
<mailto:jric...@mitre.org>>:
Thanks for the review, answers inline:
why is there a need for both scope and audience? I would
assume the scope of the authorization request is typically
turned into an audience of an access token.
You can have an audience of a single server that has multiple
scopes, or a single scope that's across multiple servers.
Scope is an explicit construct in OAuth2, and while it is
sometimes used for audience restriction purposes, they really
are independent. Note that both of these are optional in the
response -- if the AS has no notion of audience restriction in
its stored token metadata, then it just doesn't return the
"audience" field.
You are making an interesting point here. To differentiate the
resource server and the permissions of a particular at this
server makes a lot of sense. BUT: the authorization request
does not allow the client to specify both in separate
parameters. Instead both must be folded into a single "scope"
parameter. If I got your example correctly, the scope of the
request would be
scope=myserver:read
whereas the results of the introspection would be
scope=read
audience=myserver
It's probably the different semantics of scope that confused me.
No, sorry if I was unclear: scope is scope, no different
semantics. In this example case, you'd ask for
scope=myserver:read and get back scope=myserver:read. I'm not
suggesting that these be split up. Since the AS in this case
knows that there's an audience, so it can return
audience=myserver as well. The fact that it knows this through
the scope mechanism is entirely system-dependent.
I agree that the lack of a method for specifying audience does
make returning this field a little odd for simple OAuth
deployments, but since audience restriction is a big part of
clustered and enterprise deployments (in my personal
experience), then it's something very useful to have the server
return.
Generally, wouldn't it be simpler (spec-wise) to just return
a JWT instead of inventing another set of JSON elements?
What would be the utility in returning a JWT? The RS/client
making the call isn't going to take these results and present
them elsewhere, so I don't want to give the impression that
it's a token. (This, incidentally, is one of the main problems
I have with the Ping introspection approach, which uses the
Token Endpoint and invents a "token type" as its return
value.) Also, the resource server would have to parse the JWT
instead of raw JSON, the latter of which is easier and far
more common. Besides, I'd have to invent new claims for things
like "valid" and "scopes" and what not, so I'd be extending
JWT anyway.
So while I think it's far preferable to use an actual JSON
object, I'd be fine with re-using JWT claim names in the
response if people prefer that. I tried to just use the
expanded text since size constraints are not an issue outside
of a JWT, so "issued_at" instead of "iat".
Finally, note that this is *not* the same as the old OIDC
CheckId endpoint which merely parsed and unwrapped the data
inside the token itself. This mechanism works just as well
with an unstructured token as input since the AS can store all
of the token's metadata, like expiration, separately and use
the token's value as a lookup key.
I probably didn't describe well what I meant. I would suggest
to return a JWT claim set from the introspection endpoint. That
way one could use the same claims (e.g. iat instead of
issued_at) for structured and handle-based tokens. So the logic
operating on the token data could be the same.
OK, I follow you now. I'd be fine with re-using the JWT claim
names and extending the namespace with the OAuth-specific
parameters, like scope, that make sense here.
-- Justin
regards,
Torsten.
-- Justin
Am 09.01.2013 um 20:10 schrieb Justin Richer
<jric...@mitre.org <mailto:jric...@mitre.org>>:
Updated the introspection draft with feedback from the UMA
WG, who have incorporated it into their latest revision of UMA.
I would like this document to become a working group item.
-- Justin
-------- Original Message --------
Subject: New Version Notification for
draft-richer-oauth-introspection-01.txt
Date: Tue, 8 Jan 2013 14:48:47 -0800
From: <internet-dra...@ietf.org>
To: <jric...@mitre.org>
A new version of I-D, draft-richer-oauth-introspection-01.txt
has been successfully submitted by Justin Richer and posted to the
IETF repository.
Filename: draft-richer-oauth-introspection
Revision: 01
Title: OAuth Token Introspection
Creation date: 2013-01-08
WG ID: Individual Submission
Number of pages: 6
URL:http://www.ietf.org/internet-drafts/draft-richer-oauth-introspection-01.txt
Status:http://datatracker.ietf.org/doc/draft-richer-oauth-introspection
Htmlized:http://tools.ietf.org/html/draft-richer-oauth-introspection-01
Diff:http://www.ietf.org/rfcdiff?url2=draft-richer-oauth-introspection-01
Abstract:
This specification defines a method for a client or protected
resource to query an OAuth authorization server to determine meta-
information about an OAuth token.
The IETF Secretariat
_______________________________________________
OAuth mailing list
OAuth@ietf.org <mailto: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
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
