[Openid-specs-ab] Response types clarification

Torsten Lodderstedt torsten at lodderstedt.net
Thu Feb 23 18:28:35 UTC 2012


Hi John,

Am 21.02.2012 20:48, schrieb John Bradley:
> I am still trying to figure out why you are getting the impression that the Basic profile is just for JS clients?

I've got a basic understanding of how it is supposed to work for web 
applications. But I suspect I'm not the only one considering it rather 
complicated.

Let me revisit the flow (after sucessful login):

1) the OP redirects back to the redirect_uri (client web site)
2) the web site uploads HTML and pieces of JS to the client
3) the JS code extracts the id_token from the URL fragment and posts it 
to its backend

So the RP implementation requires a combination of backend and client 
side code. Furthermore, the RP needs to process two (or more? - see 
below) calls to perform the login. In contrast, a login based on the 
code flow can be implemented in the backend only and requires only a 
single request on the RP.

In my opinion, the Basic profile is opimized from a OP perspective as it 
minimizes calls and (potentially) shared state on the OP's side whereas 
the code flow is easier to use from a RPs perspective.

Further questions regarding Basic profile:
How are client and server state synchronized with respect to the user 
identity after step (3)? Independently, based on the id_token that is 
evaluated on either side? Or will the client fetch additional data?

I assume URL length restrictions do not hold for fragements, otherwise 
there would be limitations regarding id_token/access_token size.

What is your story for existing OpenID 2.0 RP? Do you intend to propose 
them to migrate to the Basic profile?

regards,
Torsten.


> John B.
>
>
> On 2012-02-21, at 4:33 PM, Torsten Lodderstedt wrote:
>
>> makes lot of sense, thank you.
>>
>> Am 21.02.2012 20:31, schrieb John Bradley:
>>> The redirect response with a id_token is no more likely to leak than a openID 2 redirect response.
>>>
>>> The main reason was functionality the fragment response works for both web servers and JS clients.
>>>
>>> Leaking the id_token is more of a privacy problem than a security one.
>>>
>>> Breno is correct that fragment has better privacy less leakage.
>>>
>>> The difference between a post redirect and JS pushing via POST is the large browser warning if you are going between https and non https endpoints and other strange side effects of cross origin POSTs.
>>>
>>> The JS version is less prone to freak out users.
>>>
>>> John B.
>>> On 2012-02-21, at 4:16 PM, Torsten Lodderstedt wrote:
>>>
>>>> Hi,
>>>>
>>>> John Bradley<ve7jtb at ve7jtb.com>   schrieb:
>>>>
>>>>> Yes query encoding of id_tokens runs the risks of leaking them through
>>>>> logs, proxys, and most of all through referrer.
>>>>>
>>>> I'm getting confused. Didn't you say in your response to my posting regarding id tokens as URI query parameters security was not the reason for not transmitting id tokens that way?
>>>>
>>>>> One of the reasons for the change in the later drafts.
>>>>>
>>>>> You can protect against referrer leaking but that requires a level of
>>>>> client sophistication that is unlikely in the wild.
>>>>>
>>>>> I should mention that POST responses were an option in openID 2.0, but
>>>>> are not in OAuth (for lots of good reasons).
>>>>>
>>>>> The fragment encoded response is also less size constrained in many
>>>>> cases, especially if the JS is using POST to push the parameters to the
>>>>> server.
>>>>>
>>>> What is the difference between the POST binding and a JS pushing the token via POST request?
>>>>
>>>> regards,
>>>> Torsten.
>>>>> John B.
>>>>> On 2012-02-21, at 3:31 PM, Breno de Medeiros wrote:
>>>>>
>>>>>> On Tue, Feb 21, 2012 at 10:27, John Bradley<ve7jtb at ve7jtb.com>
>>>>> wrote:
>>>>>>> That was the way we originally had it.   Later on people thought
>>>>> that using the OAuth multi-response type was more OAuth friendly.
>>>>>>> Originally if you had the scope openid:
>>>>>>> 1 response_type=code   both code and id_token were query encoded in
>>>>> the response
>>>>>> Query encoding id_token leads to increased privacy risks.
>>>>>>
>>>>>>> 2 response_type=token  both access_token and id_token were fragment
>>>>> encoded.
>>>>>>> There was no way to just get code or access_token, and no way to get
>>>>> just id_token.
>>>>>>> It was simpler I will give you that.
>>>>>>>
>>>>>>> It is a bit different from adding id_token to the token endpoint in
>>>>> that there is no OAuth mechanism for controlling the response from the
>>>>> endpoint.  I suppose the alternative would have been to add an extra
>>>>> parameter to the token endpoint request to say if you wanted a
>>>>> id_token.
>>>>>>> Again the problem is that the response types are not really
>>>>> combinations of token id_token but entirely new response types that
>>>>> contain the substrings token or id_token to confuse developers.
>>>>>>> John
>>>>>>> On 2012-02-21, at 3:01 PM, Justin Richer wrote:
>>>>>>>
>>>>>>>>> - just using "token" instead of all combinations of id_token and
>>>>> token ?
>>>>>>>>> The response type "token" could cause the OP to return both the
>>>>> id_token and the access token in the fragment, which is similar to the
>>>>> response of the tokens endpoint. I know this would return tokens the
>>>>> client is potentially not interested in. But this seems to be
>>>>> accepptable for the code response type.
>>>>>>>> I actually rather like this approach. It keeps the question of
>>>>> whether or not you want OpenID confined to the value of the 'scope'
>>>>> field (that is, presence of an 'openid' value in there), and it makes
>>>>> serialization of the ID Token just a part of the access token output,
>>>>> like the code flow with the token endpoint. Of course we still have to
>>>>> profile how it gets encoded, but it's ultimately another field in the
>>>>> token output.
>>>>>>>> -- Justin
>>>>>>>>
>>>>>>>>> Am 20.02.2012 20:44, schrieb John Bradley:
>>>>>>>>>> Response types are single values.   (I am starting to hate Erin's
>>>>> compromise)
>>>>>>>>>> The response types are documented in:
>>>>> http://openid.bitbucket.org/oauth-v2-multiple-response-types-1_0.html
>>>>>>>>>> The response types "code id_token",  "id_token token", and "code
>>>>> id_token token"  MUST return a id_token and the response SHOULD be
>>>>> fragment encoded.
>>>>>>>>>> Now you are asking yourself why is that SHOULD be fragment
>>>>> encoded as opposed to MUST be fragment encoded.
>>>>>>>>>> The reason for that is that the response_type registration is
>>>>> leaving wiggle room to use the same response type with post message as
>>>>> well.
>>>>>>>>>> For that to work the client would need to register a JS Origin
>>>>> and DOM Channel Names(or pick a fixed strings).  We did stub in post
>>>>> message configuration parameters, but removed them due to there not
>>>>> being a OAuth spec yet.
>>>>>>>>>> Probably more than the yes you were looking for, but the history
>>>>> provides some perspective.
>>>>>>>>>> John B.
>>>>>>>>>> On 2012-02-20, at 3:52 PM, Torsten Lodderstedt wrote:
>>>>>>>>>>
>>>>>>>>>>> Hi John,
>>>>>>>>>>>
>>>>>>>>>>> thanks for the clarification.
>>>>>>>>>>>
>>>>>>>>>>> So all response types containing the string value "id_token"
>>>>> cause the authorization server to directly return a id_token (along
>>>>> with all other parameters) to the client via fragment?
>>>>>>>>>>> regards,
>>>>>>>>>>> Torsten.
>>>>>>>>>>>
>>>>>>>>>>> Am 20.02.2012 19:48, schrieb John Bradley:
>>>>>>>>>>>> Inline
>>>>>>>>>>>>
>>>>>>>>>>>> On 2012-02-20, at 3:30 PM, Torsten Lodderstedt wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> Hi all,
>>>>>>>>>>>>>
>>>>>>>>>>>>> I'm trying to catch up with the Implementors Draft and need
>>>>> some advice from the group.
>>>>>>>>>>>>> Is it correct that "code" is the only response type, which is
>>>>> delivered to the client via URI query parameter? For all other response
>>>>> types, the response parameters are encoded within the URI fragment.
>>>>>>>>>>>> Yes
>>>>>>>>>>>>> Furthermore, is the client always issued an access token _and_
>>>>> an id_token for scope "openid" and response type "code"?
>>>>>>>>>>>> The response from the Authorization server is code as was asked
>>>>> for.
>>>>>>>>>>>> The Token endpoint includes id_token in it's response as an
>>>>> extra parameter.
>>>>>>>>>>>> So strictly speaking Yes id_token is always issued if the scope
>>>>> is 'openid'  (scope is a single value with spaces, so don't say
>>>>> includes) and the response_type is code.
>>>>>>>>>>>> However the response type is code and only code.
>>>>>>>>>>>>
>>>>>>>>>>>> The id_token is only returned if code is exchanged at the token
>>>>> endpoint for and access_token and id_token.
>>>>>>>>>>>> So I suppose you could avoid getting id_token by not exchanging
>>>>> code, but I don't think anyone is going to think that is a good idea.
>>>>>>>>>>>> The problem is that response)type only controls what comes back
>>>>> from the Authorization endpoint, and not the token endpoint.
>>>>>>>>>>>> The only option we found was overloading a scope to change the
>>>>> behaviour of the token endpoint to return the extra value.
>>>>>>>>>>>> The token endpoint response is direct, so size is not a big
>>>>> issue.  It was simpler to always return it from that endpoint than
>>>>> create a complicated way of asking for it from the token endpoint.
>>>>>>>>>>>> Worst case the response is a bit bigger, but the client ignores
>>>>> the extra parameter.
>>>>>>>>>>>> John B.
>>>>>>>>>>>>> thanks in advance,
>>>>>>>>>>>>> Torsten.
>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>> Openid-specs-ab mailing list
>>>>>>>>>>>>> Openid-specs-ab at lists.openid.net
>>>>>>>>>>>>> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>>>>>>>>> _______________________________________________
>>>>>>>>> Openid-specs-ab mailing list
>>>>>>>>> Openid-specs-ab at lists.openid.net
>>>>>>>>> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>>>>>>> _______________________________________________
>>>>>>> Openid-specs-ab mailing list
>>>>>>> Openid-specs-ab at lists.openid.net
>>>>>>> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>>>>>>>
>>>>>>
>>>>>> -- 
>>>>>> --Breno
>>>>> _______________________________________________
>>>>> Openid-specs-ab mailing list
>>>>> Openid-specs-ab at lists.openid.net
>>>>> http://lists.openid.net/mailman/listinfo/openid-specs-ab


More information about the Openid-specs-ab mailing list