<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
Hi George,<br>
<br>
wrt 1: easier to implement but less effective (in my opinion)<br>
wrt 2: <br>
could you please elaborate on the threats you want to cope with by
including the redirect URL in the refresh token request and
sub-sequently into the access token? Are you afraid of someone using
the OP as redirector? I'm asking because I would rather see the
replay of the "login" token in order to impersonate a victim as the
more serious problem. <br>
<br>
Regarding the profile: According to the core spec, section 8.2, you
can add extension parameters to any request to the token endpoint.
So this should be fine IMHO. You could also make it part of the
scope value.<br>
<br>
wrt 3: sure :-)<br>
<br>
best regards,<br>
Torsten.<br>
<br>
<div class="moz-cite-prefix">Am 03.01.2013 20:00, schrieb George
Fletcher:<br>
</div>
<blockquote cite="mid:50E5D54B.8010305@aol.com" type="cite">
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
<font face="Helvetica, Arial, sans-serif">Hi Torsten,<br>
<br>
Thanks for the response! I agree with your assessment. <br>
<br>
A couple other tweaks I've been considering...<br>
1. using short-lived tokens instead of one-time use (though I
agree one-time-use tokens are better)<br>
2. specify the re-direct URL as part of the refresh_token
request <br>
-- I think it's legal to profile the token endpoint this way,
RFC 6749 says that the AS must ignore unrecognized parameters.
If I define a profile that supports additional parameters then
they aren't unexpected. Is that valid? :)<br>
-- basically the URL is meta-data for the client2web scope and
must be supplied in order to get the token<br>
-- put the re-direct URL in the client2web token (either
directly or via server session). This protects any replay
attemptes from being able to change the redirect endpoint<br>
3. all requests to the the OP endpoint are SSL (to protect the
token as much as possible)<br>
<br>
Thanks,<br>
George<br>
<br>
</font>
<div class="moz-cite-prefix">On 1/3/13 6:46 AM, Torsten
Lodderstedt wrote:<br>
</div>
<blockquote cite="mid:50E56F7C.4070302@lodderstedt.net"
type="cite">
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
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 moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:Openid-specs-ab@lists.openid.net">Openid-specs-ab@lists.openid.net</a>
<a moz-do-not-send="true" 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>
</blockquote>
<br>
</blockquote>
<br>
</body>
</html>