Am 04.06.2010 17:04, schrieb Justin Richer:
What if you had a supertoken that was only good for getting subtokens?
In other words, only the AS knows about the supertoken (a refresh token,
perhaps?), and it allows you to get sub-tokens using the refresh flow to
access each of the different services. Then you could grab as many
different tokens with individual scopes as you want.
I've been thinking about your idea and came up with the following options.
1) authz-server token
Let's assume the authorization server issues service-specific
(ordinary) access tokens as long as it's possible. If the authorization
encounters a scope which requires different access tokens, e.g.
"imap,sip,contacts", it issues a special access token instead. Let's
call it "authz-server" token. The scope of the access token issued is
indicated by a scope return parameter.
{
"access_token":"SlAV32hkKG",
"scope":["authz-server"]
"expires_in":3600
}
So clients detect the different outcome by evaluating the scope response
parameter. Tokens with the special scope "authz-server" are used to
acquire service-specific access tokens using the new request
"issue_token" (using the assertion flow would also be an option). The
desired target service is indicated by a scope parameter. I see
different way how this request could work:
a) input: orginal scope, output: cannot work for the same reasons the
authz flow responded with a "authz-server" token
Seems we just shifted the problem :-(
b) input: orginal scope, output: multiple access tokens
Why did'nt the authorization flow respond that way? Ok, we don't
like arrays of tokens. But how can we circumvent that "problem"?
c) input: single scope element in (e.g. "imap"), output: token for
that scope element only
This works, but the client needs to call that request for each and
every string in the original scope. That may cause a lot of unnecessary
network communication.
d) input: single scope element in, output: token for that scope
element and all other applicable scopes elements
So the result would be the token with the maximum privileges out
of the "authz-token" relative to the requested scope element.
{
"access_token":"SlAV32hkKG",
"scope":["imap", "contacts"]
"expires_in":3600
}
Pro: no token array
Con: increases the number of requests a client has to exchange with the
authorization server.
2) refresh token
Apparently, the authorization server could also return a refresh token
instead of an acess token, if it encounters a multi-service scope. The
refresh token request could than be used to actually issue access
tokens. The request variants are the same as for option (1). Using
refresh tokens that way causes a significant change in the refresh token
semantics. Currently, they are (1) long-living, (2) optional for some
flows and (3) not issued by other flows. With the new semantics, (1) all
flows would need to (optionally) issue refresh tokens and (2) all kinds
of duration would be possible (from short- to long-living).
I'm still convinced that just returning multiple access token from the
authz flow (and the refresh token request) would be the simplest
solution. Since a request token is really powerful in a multi-service
situation, support for scope downgrading by the refresh token request
would be a reasonable complement.
------------------------------------------------------------------------------------------------------------
I think it's crucial to agree on the following: authorization of access
to different services, which propably require different access tokens,
within a single authorization flow is a relevant use case for OAuth2.
In my opinion, this is just a consequence of the decoupling of
authorization server and resource server(s) in OAuth2. If a single
authorization server is responsible for several resource servers, it has
to ensure privacy protection and prevention of token abuse for all of
its services. This should also include some separation between services,
no matter if one uses self-contained tokens or handles.
If we agree on the relevance of that use case, we will find a solution.
I'm open for feedback and ideas.
Any thoughts?
regards,
Torsten.
This could also be an application for the rescoping proposal, which I'm
liking more now. I've had some colleagues ask me about redelegation in
OAuth2, and I'm starting to think that the rescoping methods might be
the right answer there. I see Torsten's problem as something similar:
you get a token that's good for getting other tokens but not for
accessing protected resources (the refresh token). You then use this
token that has a "global" scope to request tokens with more directed
scopes, which can have all of the per-service signed characteristics in
the token itself that Torsten was talking about.
Would that work?
-- Justin
On Thu, 2010-06-03 at 14:27 -0400, Torsten Lodderstedt wrote:
I probably exaggerated a bit. It's not impossible but it is complex and
insecure for several reasons:
1) Such a super token would need to contain the union of all data and
permissions needed by all requested target services.
2) Not all services may by authorized to see all data contained in such
a super token (privacy!). So, you would need to built different
service-specific (encrypted) compartments within the token.
3) There are target-service-specific characteristics of such a token,
such as the audience and the signature. You would need to have such
attributes per service. Using public-key cryptography would relieve this
point but slow down processing.
4) You have to (somehow) prevent a target service from _abusing_ this
token to access another service for which the super token is valid for.
The only way I see is the usage of the client secret.
That's why I think, returning multiple tokens is much simpler.
regards,
Torsten.
Am 03.06.2010 20:10, schrieb Lukas Rosenstock:
Hi!
I'm curious why this is impossible. If access tokens are arbitrary
handles which are generated by the authorization server and
distributed to all resources, it doesn't make much difference whether
one or multiple are generated and in this case it would be better to
keep the load on the server rather complicating things for clients.
In the scenario (as you have mentioned) where access tokens are
self-contained and digitally signed, would it not be possible to
generate a "super token" which contains signatures from all resources?
I agree this token might be a bit lengthy, but is there any other
concern?!
Regards,
Lukas
2010/5/25 Torsten Lodderstedt<tors...@lodderstedt.net>:
As I said, every service in our setup needs another access token, with
different content, signed and encrypted with another shared secret. It is
technically impossible to create the super access token. Refresh tokens are
just handles representing the user's authorization and are used by the authz
server only. They therefore can represent any scope.
_______________________________________________
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
