<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Comments inline...<br>
<br>
<div class="moz-cite-prefix">On 1/3/13 2:14 PM, Torsten Lodderstedt
wrote:<br>
</div>
<blockquote cite="mid:50E5D889.6050606@lodderstedt.net" type="cite">
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
Hi George,<br>
<br>
wrt 1: easier to implement but less effective (in my opinion)<br>
</blockquote>
Agreed<br>
<br>
<blockquote cite="mid:50E5D889.6050606@lodderstedt.net" type="cite">
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>
</blockquote>
Yes and yes:) <br>
<br>
I figure that the request to get the access_token with client2web
scope is authenticated via client credentials so the AS can know
that it's a "trusted" client making the request which means the
redirect URL is more likely to be good as well. If the redirect URL
is just in the URL send to the endpoint, then any replay can also
change the destination URL.<br>
<br>
I also agree that replay of the access_token is more serious than
the open redirector attack. That said, I'd like to prevent the first
and limit the second. I'm still thinking through the issues with
implementing one-time-use tokens for this flow. If an attacker can
get access to the token after it's generated and before it's
presented, then one-time-use doesn't really prevent the attacker
from access and it locks the good user out. Risk based
authentication needs to be used for this flow as with any
authentication flow.<br>
<br>
The bigger question is probably how easy is it for an attacker to
get one of these tokens. Given that the native client is loading a
web browser then the attacker needs code on the device to capture
the token and prevent it's presentation. I suppose that an SSL MITM
attack could also expose the token though that would present even
bigger issues to the user than just this token replay.<br>
<br>
I can also envision assigning this level of SSO session a different
security characteristic than one in which the user presented their
credentials. For sure the authentication time should be the time of
authentication that generated the refresh_token. This allows for
security checks in regards to the freshness of the authentication in
any given session.<br>
<br>
Thanks,<br>
George <br>
<blockquote cite="mid:50E5D889.6050606@lodderstedt.net" type="cite">
<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>
</blockquote>
<br>
</body>
</html>