Subject: [OAUTH-WG] multiple access tokens from a single authorization flow?

From: Torsten Lodderstedt <[email-masked]>
Date: Mon, 24 May 2010 18:17:47 +0200

How many access tokens can be the result of a single OAuth authorization 
flow?

A recent discussion about OpenID Connect on the OpenId mailing list 
raised that question and I would like to initiate a discussion on this 
list.

Currently, every flow (and the refresh token request) results in a 
single access token and (optionally) a single refresh token. I think a 
single access token might not be enough when it comes to multiple scopes.

Let's assume a client wants to access the calendar and contact list of 
an end-user. Since access to the corresponding resource servers is 
managed by the same authorization server, the resources are 
distinguished by different scopes, say "calendar" and "contacts".

The client sends a request

      GET /authorize?type=web_server&client_id=s6BhdRkqt3&redirect_uri=
          
https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb&scope=calendar%20contacts HTTP/1.1
      Host: oauth.example.com

and after the authorization flow has been conducted sucessfully, the 
client's access token request would be answered as follows.

      HTTP/1.1 200 OK
      Content-Type: application/json
      Cache-Control: no-store

      {
        "access_token":"SlAV32hkKG",
        "expires_in":3600,
        "refresh_token":"8xLOxBtZp8"
      }

So the token "SlAV32hkKG" must be good for two different protected 
resources, "calendar" and "contacts".

I think this works if:
1) the token is a handle that can be swoped for user identity and 
authorization data during service request or
2) it is a self-contained token AND both resources are provided by the 
same resource server.

But what if the authorization server issues self-contained tokens and 
the resources are hosted on different, independent resource servers?

Let's assume the authorization server issues self-contained, signed, and 
encrypted bearer tokens. Signature and encryption are based on shared 
secrets between authorization server and resource server. In such a 
scenario, operational security requires to issue different tokens with 
different signature values and to encrypt those tokens with different 
keys. Moreover, the resource servers might need different user 
attributes and permissions, so even the tokens payload might differ.

I believe this scenario will become even more important with the advent 
of OpenID Connect. With OpenID connect, every client asking for an 
end-user's OpenID (+user data) and, additionally, authorization for 
another resource will need at least two tokens under the assumptions 
given above.

In order to support such scenarios, I would propose to return an array 
of access tokens from every authorization flow and the refresh request. 
An authorization server should know which resources and scopes are 
handled by what resource servers and indicate this relation in the 
access tokens response structure. This structure could be as follows.

      HTTP/1.1 200 OK
      Content-Type: application/json
      Cache-Control: no-store

      {
        "access_tokens":[
       { "token":"SlAV32hkKG", "scopes":["calendar"], "expires_in":3600},
       { "token":"SlAV32hk34", "scopes":["contacts"], "expires_in":7200},],
        "refresh_token":"8xLOxBtZp8"
      }

The scopes a particular access token is good for are indicated, so a 
client library is able to choose the right tokens for services requests. 
Alternatively it might suffice (or be better?) to indicate the sites a 
token is valid for (proposal of James Manger). It think there is no need 
for multiple refresh tokens because these tokens are handled by the 
authorization server only.

In case all resources are handled by the same resource server, the 
result would look like

      HTTP/1.1 200 OK
      Content-Type: application/json
      Cache-Control: no-store

      {
         "access_tokens":[{ "token":"SlAV32hkKG", "expires_in":3600},],
        "refresh_token":"8xLOxBtZp8"
      }

Thoughts?

regards,
Torsten.

---

From: "Keenan, Bill" <[email-masked]>
Date: Mon, 24 May 2010 10:04:37 -0700

Thanks Torsten for more of your good thinking and write-up...

At Intuit, using 1.0a, we did an experiment with one of our mobile apps using multiple tokens. The programming model of having the client maintain a mapping of token to ROA endpoint, so they used the correct token turned out to be a headache. We bailed on this, and moved to a single token, and used a mechanism server-side to manage the principle of least-privilege. As all the resources the mobile app needed were hosted by Intuit, we had this option. As we get to apps doing mashups of entities from multiple data providers, apps will need to manage multiple tokens.

At Intuit, we have been wrestling with scope for several months. With 100's going to 1000's of entities, which each have 4 - 15 verbs, expressing the set of endpoints, which a token should allow access to is complicated. I don't see an opportunity to normalize the complexity, so we are all interoperable on the cardinality of tokens to the protected resources an application needs from a specific provider. I'll push for single token in my world; others want multiple tokens (maybe).

Experience pushes me towards providing the application developer a way to say everything they need, and getting a single token to use in accessing those endpoints. Much of our access control is built around an RBAC, so issuing a token with one or more roles would provide access to all the endpoints available to the role(s). The developer learns, from SDK documentation, the roles an API is available to. In our case, we don't want developers understanding how Intuit's datacenters are organized, so we would not want them getting multiple tokens because they thought they were crossing some boundary of our internal deployment.

Right now, multiple tokens does not help me. I am sure it could help some. My caution to those going down the multi-token path is exposing more of your deployment than needed by having developers get tokens for specific areas.

BillK

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Torsten Lodderstedt
Sent: Monday, May 24, 2010 9:18 AM
To: OAuth WG ([email-masked])
Subject: [OAUTH-WG] multiple access tokens from a single authorization flow?

          

      HTTP/1.1 200 OK

      {

I think this works if:

      HTTP/1.1 200 OK

      {
        "access_tokens":[

      HTTP/1.1 200 OK

      {

Thoughts?

regards,
Torsten.

_______________________________________________
OAuth mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/oauth

---

From: Marius Scurtescu <[email-masked]>
Date: Mon, 24 May 2010 16:37:40 -0700

Hi Torsten,

I think this problem can also be solved with down-scoping support on
the refresh call (or a separate flow as Dick suggested).

The client would get back a single access token and corresponding
refresh token. It then can use the "refresh" call with an optional
scope to get a narrow access token. The original access token (the one
that came along the refresh token) would be discarded.

I realized that with down-scoping it is up to the client to do the
right thing, but I don't think that multiple access tokens can really
solve the issue. In your example, what if there are three types of
APIs:
- requiring only "calendar" scope
- requiring only "contacts" scope
- requiring both "calendar" and "contacts" scopes

How would the authorization server know how many access tokens to
issue based only on requested scopes? The client knows what narrow
access tokens it needs because it knows what APIs it intends to use.

Marius

On Mon, May 24, 2010 at 9:17 AM, Torsten Lodderstedt
<[email-masked]> wrote:
> A recent discussion about OpenID Connect on the OpenId mailing list raised
> that question and I would like to initiate a discussion on this list.
>
> Currently, every flow (and the refresh token request) results in a single
> access token and (optionally) a single refresh token. I think a single
> access token might not be enough when it comes to multiple scopes.
>
> Let's assume a client wants to access the calendar and contact list of an
> end-user. Since access to the corresponding resource servers is managed by
> the same authorization server, the resources are distinguished by different
> scopes, say "calendar" and "contacts".
>
> 2) it is a self-contained token AND both resources are provided by the same
> resource server.
>
> But what if the authorization server issues self-contained tokens and the
> resources are hosted on different, independent resource servers?
>
> different signature values and to encrypt those tokens with different keys.
> Moreover, the resource servers might need different user attributes and
> permissions, so even the tokens payload might differ.
>
> I believe this scenario will become even more important with the advent of
> OpenID Connect. With OpenID connect, every client asking for an end-user's
> OpenID (+user data) and, additionally, authorization for another resource
> will need at least two tokens under the assumptions given above.
>
> In order to support such scenarios, I would propose to return an array of
> access tokens from every authorization flow and the refresh request. An
> authorization server should know which resources and scopes are handled by
> what resource servers and indicate this relation in the access tokens
> response structure. This structure could be as follows.
>
>     HTTP/1.1 200 OK
> The scopes a particular access token is good for are indicated, so a client
> library is able to choose the right tokens for services requests.
> Alternatively it might suffice (or be better?) to indicate the sites a token
> is valid for (proposal of James Manger). It think there is no need for
> multiple refresh tokens because these tokens are handled by the
> In case all resources are handled by the same resource server, the result
> would look like
>
>     HTTP/1.1 200 OK

---

From: "Manger, James H" <[email-masked]>
Date: Tue, 25 May 2010 11:18:44 +1000

Torsten,

I obviously agree that supporting responses with multiple tokens is useful.
My original suggestion (application/credentials http://www.ietf.org/mail-archive/web/oauth/current/msg01920.html) also had multiple tokens with just one refresh_token.

I now think it would be simpler to understand, parse, specify, and agree on if we don't try to split fields between those that are common to all the tokens in a response and those that are specific to one token. A JSON array of JSON objects -- one JSON object per token -- is significantly simpler. If some information is duplicated in two tokens that is a very minor inefficiency (eg a few dozen extra bytes in one response).

Marius,
Supporting the swapping (down-scoping) of tokens with extra calls might be feasible, but it feels like a more complex and less flexible solution. It has more overhead (extra round trips). It would also need extra information to tell the client that swapping is possible, and for what scopes/servers/schemes/... it can, should or must be done.

> The original access token (the one that came along the refresh token) would be discarded.

This doesn't meet some of the requirements. Tokens for HTTP and HTTPS are needed simultaneously, not sequentially. Similarly with tokens for a 'contacts' server and a 'calendar' server; or tokens to use with BASIC and TOKEN schemes etc.

-- 
James Manger

---

From: Marius Scurtescu <[email-masked]>
Date: Mon, 24 May 2010 20:52:27 -0700

> Supporting the swapping (down-scoping) of tokens with extra calls might be feasible, but it feels like a more complex and less flexible solution. It has more overhead (extra round trips). It would…

I agree that the extra calls complicate things. How does the authz
server know how to partition the scopes to the multiple tokens? One
scope per token? What if an API requires multiple scopes?

Marius

---

From: "Manger, James H" <[email-masked]>
Date: Tue, 25 May 2010 15:04:37 +1000

> How does the authz

An AS will generally know a fair bit about the services for which it is issuing access tokens -- at least which services require what sort of token.

For situations where the client app has more knowledge than the AS on how tokens will be used, the client app could tell the AS how to partition tokens with another parameter in the user-uri (though OAuth2 doesn't necessarily have to standardise such a parameter now).

-- 
James Manger

-----Original Message-----
From: Marius Scurtescu [mailto:[email-masked]] 
Sent: Tuesday, 25 May 2010 1:52 PM
To: Manger, James H
Cc: Torsten Lodderstedt; OAuth WG ([email-masked])
Subject: Re: [OAUTH-WG] multiple access tokens from a single authorization flow?

Marius

---

From: "Richer, Justin P." <[email-masked]>
Date: Tue, 25 May 2010 07:00:08 -0400

It seems like this would make what I see as the more common case -- getting a single access token from a flow -- more complicated. Everybody pays the overhead in order to support one limited use case, which is what brought about the request token in oauth1. I don't want to always have to grab "token[0]" from the response where before i just grabbed "token". 

Also, this approach ties us to a hierarchical data representation format like JSON instead of being able to use anything that can hand us simple key-value pairs. Hashtables/dictionaries/associative-arrays are very easy to manipulate and understand in many languages.

If we can do this in a way that doesn't create overhead for the single-token case and if we can figure out a way to serialize it in a flat way as well, then I'm all for it; but I don't think we should add this much complexity just to save a few round trips. I am in favor of Dick's proposal(s) for re-scoping and revoking existing tokens using the refresh token as credential. This would allow clients to grab a refresh token then make one more call each to grab whatever access tokens they wanted to.

 -- justin
________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Manger, James H [[email-masked]]
Sent: Monday, May 24, 2010 9:18 PM
To: Torsten Lodderstedt; OAuth WG ([email-masked])
Subject: Re: [OAUTH-WG] multiple access tokens from a single authorization flow?

Torsten,

Marius,

--
James Manger

---

From: "Manger, James H" <[email-masked]>
Date: Wed, 26 May 2010 00:08:32 +1000

Justin,

> I don't want to always have to grab "token[0]" from the response where before i just grabbed "token".

Surely token[0] vs token is too trivial to be an issue.

> Also, this approach ties us to a hierarchical data representation format like JSON instead of being able to use anything that can hand us simple key-value pairs. Hashtables/dictionaries/associative…

An array is even simpler than a hashtable. An array of hashtables is still very easy to manipulate in any language. Info on any particular token can still be a hashtable.

> If we can do this in a way that doesn't create overhead for the single-token case and
> if we can figure out a way to serialize it in a flat way as well, then I'm all for it;

We can certainly figure out a way to serialise it in a flat way -- but it will look messy. OpenID manages to serialise in a flat way all sorts of structured info, even from different namespaces. Its just that few will tolerate such a mess today given the wide availability of a standard such as JSON that provides the basic structure without mess.
[Actually a good argument for JSON is we can have the more important discussions on new functionality (such as multiple tokens), on message flows, on semantics etc without constantly being concerned about serialisation, arguing about how to squeeze the logical messages into a single flat ASCII-subset hashtable.] 

> but I don't think we should add this much complexity just to save a few round trips. I am in favor of Dick's proposal(s) for re-scoping and revoking existing tokens using the refresh token as credential. This would allow clients to grab a refresh token then make one more call each to grab whatever access tokens they wanted to.

If you have multiple calls to get multiple tokens you still need client apps to be capable of managing multiple tokens. At that point you have already accepted the complexity. Whether the tokens are collected in multiple calls or parsed from one response is not the complex part.

I think the real argument is whether multiple tokens are a choice by the client app or a requirement by the server.
If it is a choice by each client app, then some client apps could be a bit simpler by choosing to only to use a single token.
On the other hand, if a server is allowed to enforce multiple tokens (for different content servers / scopes; for HTTP and HTTPS; for user-agents and web-servers etc) then there is no avoiding support for multiple tokens in generic OAuth2 client apps (and OAuth libraries in particular).

I have some reluctance in supporting multiple tokens as, say, 50% of early services might not use them initially. However there are enough real use cases that I do think OAuth2 needs to support multiple tokens. If, in a few years, 99% of services make do with a single token then no one will bother coding the extra complexity and code will trivially skip the extraneous "[" and "]" around the token info (ie no harm done for service-specific apps; limited hassle for generic apps). More likely is that if we don't support multiple tokens a bunch of use cases can't be supported and an incompatible OAuth3 will be needed next year (major harm for everyone).

--
James Manger

---

From: Luke Shepard <[email-masked]>
Date: Tue, 25 May 2010 08:27:29 -0700

Few responses on this topic:

> Surely token[0] vs token is too trivial to be an issue.

It's a pretty reasonable issue to raise. Extra complexity when not needed in the common case bogs down the spec.

> An array is even simpler than a hashtable. An array of hashtables is still very easy to manipulate in any language. Info on any particular token can still be a hashtable.

A URL of a=1&b=2 is naturally a hashtable. There is no natural way to represent arrays in URL parameters. PHP even converts normal arrays into hashtables. Generally it's much easier for developers to deal with simple key/value pairs.

> I have some reluctance in supporting multiple tokens as, say, 50% of early services might not use them initially.

Where do you get this stat from? Facebook has no need for multiple tokens, and generally 

> However there are enough real use cases that I do think OAuth2 needs to support multiple tokens. If, in a few years, 99% of services make do with a single token then no one will bother coding the extra complexity and code will trivially skip the extraneous "[" and "]" around the token info (ie no harm done for service-specific apps; limited hassle for generic apps). More likely is that if we don't support multiple tokens a bunch of use cases can't be supported and an incompatible OAuth3 will be needed next year (major harm for everyone).

As Justin suggested, I think it would be a good exercise to figure out how your requirements could be represented as a backwards-compatible extension instead of increasing complexity of the core spec. I'm confident that this would not require a rewrite of the protocol.

---

From: Marius Scurtescu <[email-masked]>
Date: Tue, 25 May 2010 10:29:24 -0700

> An AS will generally know a fair bit about the services for which it is issuing access tokens -- at least which services require what sort of token.

Ideally the AS should not have intimate knowledge of the services,
that does not scale.

Also, the client is requesting access to a set of scopes, and not to a
set of services, not always the same thing.

> For situations where the client app has more knowledge than the AS on how tokens will be used, the client app could tell the AS how to partition tokens with another parameter in the user-uri (thoug…

I think this complicates the spec quite a bit.

Down-scoping really solves the problem and keeps the spec simple. The
only drawback is that extra calls are needed.

Marius

---

From: Torsten Lodderstedt <[email-masked]>
Date: Tue, 25 May 2010 22:21:22 +0200

Thank you all for your feedback on my posting. I will answer in a single 
response.

To start with I want to clarfiy where I come from and what way my 
thoughts went along. This will hopefully help to understand the 
limitation of OAuth2 I want to address.

<why different tokens?>

At Deutsche Telekom we provide a variety of IP-based services to our 
customers, for example e-Mail, calendar, contacts, web storage, Voice 
over IP (SIP), IP TV, Video on demand, personal video recorder and much 
more.

More and more of these services are made available to the outside by way 
of REST or SOAP-based web services. Authorization is provided  by a 
central token service, which issues user-related and self-contained 
security tokens clients use in subsequent services request to authorize 
on behalf of end-users. Our goal is that authorization of service access 
shall be possible w/o further interaction with identity management 
systems, which gives as maximum performance and scalability.

Therefore every token contains the user attributes (like name) and 
permissions (e.g. the user is allowed to view channel X or has a web 
storage quota of 2GB) as required by a certain service. And every 
service has other requirements: For example, the EPG service needs all 
TV-channel-related permissions whereas the web storage service may 
require the respective storage-related permissions and quotas. For 
privacy reasons, the user identifiers in the tokens may also vary among 
services. Some service get access to universal identifiers whereas other 
services only get to know service-specific identifiers.

Token security is based on digital signatures (HMAC because it's faster 
than public-key based signatures), encryption (in order to prevent 
clients from eavesdropping internal and personal data), token lifetime 
and audience. You might have guessed already, we orginally started w/ 
SAML assertions as token format. Now we also use a less 
noisy, bandwith-optimized binary token format.

Our services are operated by various internal units or external partners 
- that's a business-driven decision and not a technical one. So 
operational security forces us to use different shared secrets for 
different services.

Bottom line: there are plenty of different services with different 
characteristics needing different user data and permissions, operated by 
different organisations. We use self-contained tokens for performance 
and scalability reasons. Using a single token for all services is not an 
option in our landscape. For example, putting all permissions and 
attributes of a single user out of our user directory into one token 
would probably result in tokens with >100 KBytes in size. Probably it is 
a unique environment, but I don't believe that.

<why multiple tokens at once?>

Our current token service implementation is partially based on OAuth 
1.0a and we intend to move towards OAuth2 when it becomes stable. Our 
current implementation (as the current OAuth2 draft, too) only supports 
the authorization of access to a single service. In the past I thought 
this would be an acceptable limitation since most (if not all) 
applications I know access a single service only. The OpenId Connect 
proposal made me reconsidering my opinion. As soon as a OpenID connect 
client needs to access other resources beside the user data service, 
there will be a need for more than one access token even for average 
clients (at least in our setup).

And, combined clients are comming around the edge even here at Deutsche 
Telekom! For example, there is a client visualizing data from e-Mail and 
Webstorage in a single view. Our suppose our EPG client, which is used 
to program personal digital videorecorder at home from the smartphone. 
This client could be extended to add reminders into the users calendar 
for important live broadcasts (service: calendar), to send e-Mails with 
recommandations to friends (from contacts) using the e-Mail service. In 
the end, I think it is up to the client to compose services into end 
user applications.

If we accept multi-service clients, the question is how will these 
clients be supported by the OAuth standard?

With the current draft, the client has to send the user through the 
authz process n-times (n = number of services). This would look this:

user accesses client
REDIRECT AS
Login at AS
User Consent service 1
REDIRECT back
get access token for service 1
REDIRECT AS
SSO at AS
User Consent service 2
REDIRECT back
get access token for service 2
REDIRECT AS
SSO at AS
User Consent service 3
REDIRECT back
get access token for service 3

What a user experience is that? And imagine such a use case for the 
device flow :-(

Do we have other options to perform this process more user-friendly?

First of all, how does the client request authorization for different 
services? As far as I see, the scope parameter is the only way to pass 
such information to the authorization server. So instead of mererly 
denoting permissions, we can use scopes as kind of service id + permissions.

Which options do we have for returning tokens to the client?

As proposed by Marius, the authorization server could issue a refresh 
token and the client could use the refresh request in combination with 
the downscoping feature in order to acquire access tokens.
Consequences?
In the setup illustrated above, the authorization server cannot create 
any access token (or an arbitrary one), it can only return a refresh 
token. This would mean to make the access token response parameter 
optional. Here I'm colliding with my mental picture of refresh tokens as 
long-living and storable tokens. Are these refresh tokens still 
long-living or as short-living as a Kerberos TGT? If they are still 
long-living, what about the use cases where we don't want to return 
refresh tokens? As far as I remember, user agent and username/password 
flow were candidates. How shall we handle them?

Coming back to my original proposal: The authorization server could also 
issue multiple access tokens and (optionally) a refresh token - 
preserving the refresh token semantics.

Justin pointed out that my original proposal added complexity to the 
simplest use case even if the authorization server does not issue 
multiple tokens. I understand your objection and would like to suggest a 
modified response structure. Instead of putting all access token into an 
array, the authz server could also use the structure as defined in the 
current draft and use another list of "additional_access_tokens", if 
more than one token has been created.

      HTTP/1.1 200 OK

      {
        "access_token":"SlAV32hkAB",
        "scopes":"calendar",
        "expires_in":3600,
        "refresh_token":"8xLOxBtZp8"
        additional_access_tokens = [{ "token":"SlAV32hkKG", 
"scopes":["calendar"], "expires_in":3600}, ...]
      }

So in the simplest case, the response would look the same as before.

      HTTP/1.1 200 OK

      {
        "access_token":"SlAV32hkAB",
        "scopes":"calendar",
        "expires_in":3600,
        "refresh_token":"8xLOxBtZp8"
      }

Thoughts?

regards,
Torsten.

---

From: Marius Scurtescu <[email-masked]>
Date: Tue, 25 May 2010 13:36:59 -0700

On Tue, May 25, 2010 at 1:21 PM, Torsten Lodderstedt
<[email-masked]> wrote:
>
> As proposed by Marius, the authorization server could issue a refresh token
> and the client could use the refresh request in combination with the
> downscoping feature in order to acquire access tokens.
> Consequences?
> In the setup illustrated above, the authorization server cannot create any
> access token (or an arbitrary one), it can only return a refresh token. This
> would mean to make the access token response parameter optional. Here I'm
> colliding with my mental picture of refresh tokens as long-living and
> storable tokens. Are these refresh tokens still long-living or as
> short-living as a Kerberos TGT? If they are still long-living, what about
> the use cases where we don't want to return refresh tokens? As far as I
> remember, user agent and username/password flow were candidates. How shall
> we handle them?

I think the authz server can create an access token that will grant
access to all requested scopes, just as the corresponding refresh
token. If the client intends to do down-scoping then it will probably
just discard this initial access token.

One way to ensure that the client is not lazy and it is not using the
broadly scoped access token is to have services refuse access tokens
that are not narrowed down to only what the service needs.

Marius

---

From: Torsten Lodderstedt <[email-masked]>
Date: Tue, 25 May 2010 22:46:18 +0200

> that are not narrowed down to only what the service needs.

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.

regards,
Torsten.

---

From: Marius Scurtescu <[email-masked]>
Date: Tue, 25 May 2010 13:51:19 -0700

On Tue, May 25, 2010 at 1:46 PM, Torsten Lodderstedt
<[email-masked]> wrote:
>>> token
>>> any
> 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.

I see, thanks for clarifying.

Marius

---

From: Thomas Hardjono <[email-masked]>
Date: Wed, 26 May 2010 13:14:46 -0400

Hi Torsten,

Looking at your example below (with the user having 
to login/consent several times), it seems what is needed
is multiple short-term (narrower) tokens that is provably
derived from one single (parent) longer-life token.
So the human user would need to consent only once
to the parent longer-life token, and the client would
fetch the multiple shorter-life tokens automatically.
The keyword here is "provably" (which may be
read as "cryptographically provable").

BTW. Apologies for the history lesson, but
this was the same problem with Kerberos when
it was first deployed at MIT project Athena in the late 1980s.
The solution was to create a separate Ticket-Granting-Ticket (TGT)
with the user being prompted for a password only once.
Then the Kerberos client would obtain Service Tickets
(to access resources) using the TGT.

/thomas/

> Sent: Tuesday, May 25, 2010 4:21 PM
> .....

---

From: Thomas Hardjono <[email-masked]>
Date: Wed, 26 May 2010 13:36:47 -0400

Apologies if I'm speaking out of school :) but it seems
the Refresh Token offers an opportunity for
solving Torsten's problem.

- Instead of calling it a Refresh Token, why not
redefine it as a Service Token (or Sub-Access Token)
with a specific scope and intended Resource Server.

- In 3.3.1., when the Client perform authentication
it needs to identify the multiple Resource Servers
it seeks to access (each with a separate scope
and requested access lifetimes).

- In the Access Token Response (3.3.2.1) coming
back from the Authorization Server, the response
would contain a matching number of Service Tokens,
each with a separate access_secret, scope, expires_in
values.

- The Client can then use any of these Service Tokens
independent of the original Access Request, until
the expiration of the Service Token. No need for
the Client to prompt the human user.

/thomas/

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Marius Scurtescu
> Sent: Tuesday, May 25, 2010 4:51 PM
> To: Torsten Lodderstedt
> Cc: OAuth WG ([email-masked])

---

From: Torsten Lodderstedt <[email-masked]>
Date: Wed, 26 May 2010 20:17:59 +0200

I also realized the parallels of refresh tokens and TGTs. That's why I said

"Are these refresh tokens still long-living or as short-living as a 
Kerberos TGT?"

when discussing Marius's proposal. In my opinion, the main difference 
between TGT and refresh token is the live-time. Refresh tokens may have 
a unlimited validity whereas TGTs as far as I know live for at least 24h 
(incl. re-newal).

We can use refresh tokens the same way as TGTs but than every flow must 
return a refresh token and, in my opinion, aquisition of access tokens 
(or call it services tickets :-)) should be a second step using the 
refresh request.

At request level, this would look as follows

Obtaining token flow result

       HTTP/1.1 200 OK

       {

  Acquiring token for scope "calendar"

      Host: server.example.com
      Content-Type: application/x-www-form-urlencoded

      type=refresh_token&client_id=s6BhdRkqt3&client_secret=8eSEIpnqmM&
refresh_token=8xLOxBtZp8&scope=calendar

      HTTP/1.1 200 OK

      {
        "expires_in":3600
      }

  Acquiring token for scope "contacts"

      Host: server.example.com
      Content-Type: application/x-www-form-urlencoded

      type=refresh_token&client_id=s6BhdRkqt3&client_secret=8eSEIpnqmM&
refresh_token=8xLOxBtZp8&scope=contacts

      HTTP/1.1 200 OK

      {
        "expires_in":3600
      }

regards,
Torsten.

>> Torsten Lodderstedt

---

From: Thomas Hardjono <[email-masked]>
Date: Wed, 26 May 2010 14:27:52 -0400

I do realize several people on this list should see the parallel :)   Several folks at the last IETF OAuth meeting also brought-up the similarities.

One of the aspect unclear to me with OAuth draft-05 is the cryptographic relationship between the Refresh Token ("8xLOxBtZp8") and the Calendar token ("SlAV32hkKG") & Contacts token ("SlAV32hkAB").  That is, how can a verifying third party be satisfied that the access came from the same Client/Session.

/thomas/

__________________________________________

> From: Torsten Lodderstedt [mailto:[email-masked]]
> Sent: Wednesday, May 26, 2010 2:18 PM
> To: Thomas Hardjono

---

From: "Richer, Justin P." <[email-masked]>
Date: Wed, 26 May 2010 14:49:50 -0400

>From what I understand, there is no inherent similarity between the two. You *can* wire up your AS and PR to do some verification of that caliber, but it's not required by the OAuth spec. For cases when the AS and PR are collapsed into a single system (which is a large percentage of use cases outside of the Big Internet Companies, from what I gather), then all you need to do to prove that the access and refresh token are related is by a lookup to a local database table. 

 -- justin

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Thomas Hardjono [[email-masked]]
Sent: Wednesday, May 26, 2010 2:27 PM
To: Torsten Lodderstedt
Cc: OAuth WG ([email-masked])
Subject: Re: [OAUTH-WG] multiple access tokens from a single authorization flow?

/thomas/

---

From: Thomas Hardjono <[email-masked]>
Date: Wed, 26 May 2010 15:49:01 -0400

I hope to be writing-up a draft that will include
text that discusses similarities.

In terms of operability, one possible approach
is placing a KDC behind an OAuth AS,
and making the OAuth RS a Kerberized service.

All Krb messages would be encoded in GSSAPI token
format (base64 encoded), as is done in
other specs.  This makes all the Krb messages
opaque to OAuth.

What I then need is some way to indicate
in the access_token, refresh_token and client_secret
that the contained data is Kerberos data.

Would this work?

/thomas/

> From: Richer, Justin P. [mailto:[email-masked]]
> Sent: Wednesday, May 26, 2010 2:50 PM
> To: Thomas Hardjono; Torsten Lodderstedt
> Subject: RE: [OAUTH-WG] multiple access tokens from a single authorization
> flow?
> 
> From what I understand, there is no inherent similarity between the two. You
> *can* wire up your AS and PR to do some verification of that caliber, but
> it's not required by the OAuth spec. For cases when the AS and PR are
> collapsed into a single system (which is a large percentage of use cases
> outside of the Big Internet Companies, from what I gather), then all you need
> to do to prove that the access and refresh token are related is by a lookup
> to a local database table.
> 
>  -- justin
> 
> I do realize several people on this list should see the parallel :)   Several
> folks at the last IETF OAuth meeting also brought-up the similarities.
> 
> One of the aspect unclear to me with OAuth draft-05 is the cryptographic
> relationship between the Refresh Token ("8xLOxBtZp8") and the Calendar token
> ("SlAV32hkKG") & Contacts token ("SlAV32hkAB").  That is, how can a verifying
> third party be satisfied that the access came from the same Client/Session.
> 
> /thomas/
> 
> 
> 
> > >> Subject: Re: [OAUTH-WG] multiple access tokens from a single
> authorization
> > >> flow?
> > >>
> > >> .....

---

From: Dick Hardt <[email-masked]>
Date: Wed, 26 May 2010 14:44:12 -0600

Are you referring to my OpenID v.Next NewSocialService scenario?

What issues do you see doing this in v.Next rather than OAuth?

Using OpenID allows the client/RP to only discover the user's OP, which
knows where the user's calendar / address book is.

Having the OP as an intermediary allows it to interact with the user to
select which address book or calendar to provide in a particular context
cleanly solves the multiple service provider issue

-- Dick

---

From: Torsten Lodderstedt <[email-masked]>
Date: Fri, 28 May 2010 08:57:04 +0200

I'm refering to a siuation where a single authorization server manages 
access to multiple resource serveres and a client seeks authorization 
for some of this resource servers. I assume this would also happen in 
your scenario once the OP discovers that access to calendar and address 
book are protected by the same authorization server. How would you 
envision the authorization process (user consent) and token exchange 
between OP, authorization server and RP/client in such a situation?

regards,
Torsten.

> Using OpenID allows the client/RP to only discover the user's OP, 
> which knows where the user's calendar / address book is.
>
> Having the OP as an intermediary allows it to interact with the user 
> to select which address book or calendar to provide in a particular 
> context cleanly solves the multiple service provider issue
>
> -- Dick
>
>
> On Mon, May 24, 2010 at 10:17 AM, Torsten Lodderstedt 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     How many access tokens can be the result of a single OAuth
>     authorization flow?
>
>     A recent discussion about OpenID Connect on the OpenId mailing
>     list raised that question and I would like to initiate a
>     discussion on this list.
>
>     single access token and (optionally) a single refresh token. I
>     think a single access token might not be enough when it comes to
>     multiple scopes.
>
>     Let's assume a client wants to access the calendar and contact
>     list of an end-user. Since access to the corresponding resource
>     servers is managed by the same authorization server, the resources
>     are distinguished by different scopes, say "calendar" and "contacts".
>
>         Host: oauth.example.com <http://oauth.example.com>
>
>     and after the authorization flow has been conducted sucessfully,
>     the client's access token request would be answered as follows.
>
>         HTTP/1.1 200 OK
>     2) it is a self-contained token AND both resources are provided by
>     the same resource server.
>
>     But what if the authorization server issues self-contained tokens
>     and the resources are hosted on different, independent resource
>     servers?
>
>     Let's assume the authorization server issues self-contained,
>     signed, and encrypted bearer tokens. Signature and encryption are
>     based on shared secrets between authorization server and resource
>     server. In such a scenario, operational security requires to issue
>     different tokens with different signature values and to encrypt
>     those tokens with different keys. Moreover, the resource servers
>     might need different user attributes and permissions, so even the
>     tokens payload might differ.
>
>     I believe this scenario will become even more important with the
>     advent of OpenID Connect. With OpenID connect, every client asking
>     for an end-user's OpenID (+user data) and, additionally,
>     authorization for another resource will need at least two tokens
>     under the assumptions given above.
>
>     In order to support such scenarios, I would propose to return an
>     array of access tokens from every authorization flow and the
>     refresh request. An authorization server should know which
>     resources and scopes are handled by what resource servers and
>     indicate this relation in the access tokens response structure.
>     This structure could be as follows.
>
>         HTTP/1.1 200 OK
>     The scopes a particular access token is good for are indicated, so
>     a client library is able to choose the right tokens for services
>     requests. Alternatively it might suffice (or be better?) to
>     indicate the sites a token is valid for (proposal of James
>     Manger). It think there is no need for multiple refresh tokens
>     because these tokens are handled by the authorization server only.
>
>     [email-masked] <mailto:[email-masked]>