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
