[Openid-specs-ab] Response types clarification

Torsten Lodderstedt torsten at lodderstedt.net
Tue Feb 21 19:16:38 UTC 2012



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