[Openid-specs-ab] Bootstrapping a web session with OpenID Connect and OAuth2?

[George Fletcher]

I'm trying to define the best way to accomplish the following scenario 
using the latest OpenID Connect / OAuth2 specs.

    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.

    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).

    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).


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.

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.

Problems with this approach are...
* 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.
* 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)
* 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).

Does anyone else have this use case and/or interested is defining a 
standard way to do it? I have a few ideas:)

Thanks,
George
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20130102/428fb58a/attachment.html>