<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<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>
</body>
</html>