<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
Hi George,<br>
<br>
we have similar use cases.<br>
<br>
- I doubt the standard OpenId connect messages would be appropriate
here. The app, which started the process, is not supposed to receive
the login response. And the portal the user wants to access in the
newly spawned user agent typically initiates it own login request.
This renders at least the following parameters (if not the whole
scheme) useless for this use case:<br>
* response_type<br>
* scope<br>
* redirect_uri<br>
* nonce<br>
<br>
- I'm also unsure whether id tokens would add any benefit over
"plain old" access tokens.<br>
<br>
- In my opinion, it makes sense to more or less stick to your
original design. I would use an access token with a special scope to
secure the process. The client could sent this access token to a
bootstrap endpoint exposed by the OP (or its web/sso part to be more
precisely). So in this case, the web/sso part of the OP is the
resource server consuming this access token. <br>
- In order to support this use cases, I would issue a (long-living)
refresh token to the native app, which can in turn be used to
acquire access tokens for SSO session boostrapping (or any other
access token as well). <br>
- It might be advisable to make access tokens for this use case one
time use in order to reduce the risk if such an (login) access token
is leaked.<br>
- I would assume that the URL the user agent shall be redirected to
is the landing page of one of the other RPs linked to the particular
OP. So the request could refer to one of them.<br>
<br>
best regards,<br>
Torsten.<br>
<br>
<div class="moz-cite-prefix">Am 02.01.2013 20:59, schrieb George
Fletcher:<br>
</div>
<blockquote cite="mid:50E491A5.5060708@aol.com" type="cite">
<meta http-equiv="content-type" content="text/html;
charset=ISO-8859-1">
<font face="Helvetica, Arial, sans-serif">I'm trying to define the
best way to accomplish the following scenario using the latest
OpenID Connect / OAuth2 specs.<br>
</font>
<blockquote><font face="Helvetica, Arial, sans-serif">Basically,
one of our currently supported APIs is something we call
'client2web' which allows a client with a long lived token
(think OAuth2 token with offline_access) to construct a signed
URL (signing mechanism based on OAuth1) to load into a
browser. The 'client2web' API endpoint processes the requests
by first validating the signature, and then validating the
passed "access_token" to determine the user. If everything
validates correctly, the AS/OP constructs a new web session
for the user and redirects the browser to the requested
destination (one of the signed URL parameters) setting
authentication session cookies in the process.</font><br>
<br>
<font face="Helvetica, Arial, sans-serif">A few other features
of this process. The access_token is an encrypted blob, and
the signing secret is unique to each authorization where the
user authenticates with their password (i.e. the signing
secret is a function of the password). Also, the RP to which
the browser is redirected can determine the identity of the
user in the browser by making an AJAX API call back to the AS
(note that this has negative security ramifications).</font><br>
<br>
<font face="Helvetica, Arial, sans-serif">The two main use cases
for the above scenario are desktop based application and/or
mobile apps (all more or less fall into the native apps
category).</font><br>
</blockquote>
<font face="Helvetica, Arial, sans-serif"><br>
So, in OpenID Connect, an id_token can be passed as a hint to
the OP, but that's about all I could find that the OP allows as
it relates to the "client" providing an assertion for the user.
Assuming the native app starts with OpenID Connect, then it
could save the id_token and present it later... though I don't
believe that works well for really long lived tokens.<br>
<br>
I was thinking that it might make sense to allow an id_token to
be constructed from an access_token via an endpoint at the OP
(token endpoint, grant=refresh_token&...) and then pass the
id_token in the normal OpenID Connect flow. Sort of an STS
flow... exchange access_token for id_token. The privilege of
doing so would require an explicit scope so that the user could
consent to this behavior by the native app.<br>
<br>
Problems with this approach are...<br>
* in the normal OpenID Connect flow that contains an id_token as
a hint, the id_token is compared against browser cookies to
determine if the user and session are the same. In this case
there wouldn't be any browser cookies to compare against. <br>
* using the callback_url as the redirect URL causes registration
problems (native app has to register the web app as one of it's
callback urls)<br>
* using the callback_url as the redirect URL forces all RPs to
have a special endpoint that can handle OpenID Connect
semantics. In our case, I really want the OP to just set browser
cookies and let the RP figure out who the user is (e.g. implicit
flow with prompt=none).<br>
<br>
Does anyone else have this use case and/or interested is
defining a standard way to do it? I have a few ideas:)<br>
<br>
Thanks,<br>
George</font> <br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Openid-specs-ab mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Openid-specs-ab@lists.openid.net">Openid-specs-ab@lists.openid.net</a>
<a class="moz-txt-link-freetext" href="http://lists.openid.net/mailman/listinfo/openid-specs-ab">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a>
</pre>
</blockquote>
<br>
</body>
</html>