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
Content-Type: application/json
Cache-Control: no-store
{
"refresh_token":"8xLOxBtZp8"
}
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
Content-Type: application/json
Cache-Control: no-store
{
"access_token":"SlAV32hkKG",
"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
Content-Type: application/json
Cache-Control: no-store
{
"access_token":"SlAV32hkAB",
"expires_in":3600
}
regards,
Torsten.
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/
-----Original Message-----
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of
Torsten Lodderstedt
Sent: Tuesday, May 25, 2010 4:21 PM
To: OAuth WG (oauth@ietf.org)
Subject: Re: [OAUTH-WG] multiple access tokens from a single authorization
flow?
.....
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
Content-Type: application/json
Cache-Control: no-store
{
"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
Content-Type: application/json
Cache-Control: no-store
{
"access_token":"SlAV32hkAB",
"scopes":"calendar",
"expires_in":3600,
"refresh_token":"8xLOxBtZp8"
}
Thoughts?
regards,
Torsten.
_______________________________________________
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
