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
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
