Hi Igor,
I have no doubt that the description makes sense, but I have not quite
grasped it. I think that what you mean is the case when I want to get
to a web site (relying party) with an OpenID. Here I should get from
the identity provider (after it authenticates me) not only an
assertion to pass back to the relying party but also a token.
But what I don't understand is what access rights will this token give
me. Is that that my identity provider is expected to know what access
rights I have on different sites? This is the part that I am lost in.
Maybe it would be easy to explain this idea by applying it to the
classical OAuth use case (i.e., getting a printing service to print my
photos on a photo album site)?
If there is something written on this case, maybe you could share it?
I am actually very interested in this subject and glad that you
brought it up.
I didn't have anything in my pocket when I asked Brian regarding
convergence of OpenId and OAuth. It was just an idea coming into my
mind, when he pointed out the security risk imposed by storing tokens in
a Oauth client. OAuth is great in that it eliminates the need to handle
user passwords on consumer sites, the same objective can be achieved
when using OpenId for web site login. So combining OAuth with OpenId for
this category of applications might be beneficialy.
And you are right, the key is the relationship between OpenId OP and
OAuth Autorization Server the target services trust in. Below I
summarize two possible setups. Note it is more brainstorming then
thought through in detail. (I intentionally left out some details about
privacy and security).
*strong coupling
In the simplest case, the photo album site is offered by a large service
provider, which offers many different sites (products) to users. In
order to offer a seamless user experience and facilitate security for
web applications, the service provider uses a central user/authorization
data management and a SSO server based on OpenId. So in comparison to
classical OpenId, the OpenId protocol is used under the hood but the
only OP supported for web site login is the provider's OP. Web service
access is secured using OAuth tokens. Tokens are issued by a single
OAuth service for all sites, which also operate on the central
user/authorization data management.
The provider also offers a photo print service to its customers, which
is bound to the providers photo album site. Login at the photo print
service could be performed as follows:
1) Photo print service initiates authentication and passes an additional
parameter, which identifies the required service (photo album)
2) OP authenticates the user
3) OP shows user consent page. In this case not only asking for the
approval to send attributes but also permissions to the RP
4) OP has access to user data base and directly creates tokens (it could
delegate this part to the OAuth service, too)
5) Tokens are sent back with the response to the photo print service
Such a strong coupling can be found in the environment I currently work in.
Benefits: the typical benefits expected by standards (maturity,
know-how, libraries,...), it would especially simplify the the
implementation of both web services and applications and decrease cost.
*loose coupling
Let's try now to generalize the idea a bit.
Assumptions:
- the photo album site uses OpenId and operates a OAuth service
- the photo print service site uses OpenId as well
- users can use any OpenId server they like for both services as long as
the use the same OpenId for both services
- OAuth user consent pages shall be delivered by the OAuth server
because of user recognition
1) Photo print service initiate authentication, passes additional
parameters, which identify the required realms and services
2) OP authenticates the user
3) OP shows usual user consent page (attributes).
4) OP looks up OAuth provider associated with target web services (e.g.
using YADIS/XRDS)
5) OP sents request to oauth provider along with the authenticated openid
Note: there has to be a trust relationship between OAuth server and
OpenId OP. I see different options here: pre-shared secrets, something
based on OpenId discovery, probably the registration free process based
on public key as suggested by Eran (posting from 02/19/2010)
6) OAuth server looks up its database for a user associated with the
given openid
7) If the user exists, the OAuth responds with a redirect URL for the
tokens authorization process
8) OP redirects user browser to OAuth server
9) OAuth server requests users approval for photo print service
+ asks the user to allow the OpenID OP to automatically request tokens
for the photo print service in future authentication transactions
10) OAuth server creates tokens and encrypts them using the photo
service consumer_secret (prevents eavesdropping by OP and on transit)
+ OAuth server issues a token to the OpenId server to be used for
further tokens acquisitions (based on the approval in step 9+)
11) OAuth redirects user browser back to OpenId OP along with the
encrypted token(s)
12) OP redirects user browser back, the response contains the usual
OpenId parameters + the OAuth tokens
What do you think?
regards,
Torsten.
Igor
Torsten Lodderstedt wrote:
Suppose a webite wants to (1) login users interactively and (2)
access web services on behalf of those users which are secured by
tokens. From my point of view, one could integrate token issuance
into the login process. So the application might perform login via
Openid and request access tokens as additional results of the login
process from the identity provider. Does this make sense?
regards,
Torsten.
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
