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

George Fletcher gffletch at aol.com
Thu Jan 3 20:27:04 UTC 2013


Comments inline...

On 1/3/13 2:14 PM, Torsten Lodderstedt wrote:
> Hi George,
>
> wrt 1: easier to implement but less effective (in my opinion)
Agreed

> wrt 2:
> 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.
Yes and yes:)

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.

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.

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.

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.

Thanks,
George
>
> 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.
>
> wrt 3: sure :-)
>
> best regards,
> Torsten.
>
> Am 03.01.2013 20:00, schrieb George Fletcher:
>> Hi Torsten,
>>
>> Thanks for the response! I agree with your assessment.
>>
>> A couple other tweaks I've been considering...
>> 1. using short-lived tokens instead of one-time use (though I agree 
>> one-time-use tokens are better)
>> 2. specify the re-direct URL as part of the refresh_token request
>>   -- 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? :)
>>   -- basically the URL is meta-data for the client2web scope and must 
>> be supplied in order to get the token
>>   -- 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
>> 3. all requests to the the OP endpoint are SSL (to protect the token 
>> as much as possible)
>>
>> Thanks,
>> George
>>
>> On 1/3/13 6:46 AM, Torsten Lodderstedt wrote:
>>> Hi George,
>>>
>>> we have similar use cases.
>>>
>>> - 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:
>>> * response_type
>>> * scope
>>> * redirect_uri
>>> * nonce
>>>
>>> - I'm also unsure whether id tokens would add any benefit over 
>>> "plain old" access tokens.
>>>
>>> - 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.
>>> - 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).
>>> - 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.
>>> - 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.
>>>
>>> best regards,
>>> Torsten.
>>>
>>> Am 02.01.2013 20:59, schrieb 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
>>>>
>>>>
>>>> _______________________________________________
>>>> Openid-specs-ab mailing list
>>>> Openid-specs-ab at lists.openid.net
>>>> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>>>
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20130103/5b86ebfb/attachment-0001.html>


More information about the Openid-specs-ab mailing list