Re: [OAUTH-WG] [Openid-specs-ab] OAuth Security Topics -- Recommend authorization code instead of implicit

[Torsten Lodderstedt <[e-mail]>]

I still don’t understand why the use case must be solved using a flow issuing something in the front channel. 

I would also like to take a closer look. Can you or Nat provide pointers to existing implementations? 

> Am 27.11.2018 um 21:36 schrieb John Bradley <[e-mail]>:
> 
> I understand that, but hat is Nat's concern as I understand it.
> 
> When we say no implicit people, have a problem because implicit is imprecise.
> 
> We are saying no AT returned in the response from the authorization endpoint.
> 
> Nat points out that id_token may contain AT for the self issued client.
> 
> So unless we say that is OK if the AT are sender constrained we wind up implying that a OpenID profile of OAuth is in violation of the BCP.
> 
> I am just trying to make sure everyone is on the same page with why Nat was -1.
> 
> It really has nothing to do with the SPA use case.
> 
> John B.
> 
>> On 11/27/2018 5:28 PM, Torsten Lodderstedt wrote:
>> Hi John,
>> 
>> as you said, self issued IDPs (https://openid.net/specs/openid-connect-core-1_0.html#SelfIssued) are supposed to provide the response type „id_token“ only. I don’t think the proposal being discussed here is related to this OIDC mode.
>> 
>> best regards,
>> Torsten.
>> 
>>> Am 27.11.2018 um 20:54 schrieb John Bradley <[e-mail]>:
>>> 
>>> I talked to Nat about this a bit today.
>>> 
>>> The thing he is concerned about is mostly around the self issued IDP that doesn't have a token endpoint(atleast not easaly).
>>> 
>>> The main use case for that is the id_token response type where claims are retuned in the id_token.
>>> 
>>> Because it is fragment encoded some people call that implicit.   That is not what we are trying to stop.
>>> 
>>> In some cases in that flow there may be distributed claims returned with access Token inside the id_token.    I think most people would agree that those should be pop or sender constrained tokens.
>>> 
>>> In the case of self issued the RP would be a server and could do sender constrained via some mechinisim that is yet to be defined.
>>> 
>>> So if someone wanted to return a access token in a id_token to do distributed claims I don't think we have a problem with that as long as the token is protected by being sender constrained in some reasonable way.
>>> 
>>> This is a touch hypothetical from the basic OAuth perspective, so I don't know how deep we want to go into it.
>>> 
>>> I think the point is not to accidently prohibit something that could be done in future.
>>> 
>>> I also think we should not conflate confidential clients that can authenticate to the token endpoint with sender constrained/PoP clients that can deal with bound tokens.   Yes both have keys but it is better to describe them separately.
>>> 
>>> John B.
>>> 
>>> On Tue, Nov 27, 2018, 4:30 PM Torsten Lodderstedt via Openid-specs-ab <[e-mail] wrote:
>>> Hi Nat,
>>> 
>>> I understand you are saying your draft could provide clients with an application level mechanism to sender constrain access tokens. That’s great!
>>> 
>>> But I don’t see a binding to response type „token id_token“. Why do you want to expose the tokens via the URL to attackers?
>>> 
>>> You could easily use your mechanism with code. That would also give you the chance to really authenticate the confidential client before you issue the token.
>>> 
>>> kind regards,
>>> Torsten.
>>> 
>>>> Am 27.11.2018 um 16:57 schrieb Nat Sakimura <[e-mail]>:
>>>> 
>>>> I am not talking about SPA.
>>>> The client is a regular confidential client that is running on a server.
>>>> 
>>>> Best,
>>>> 
>>>> Nat Sakimura
>>>> 
>>>> 
>>>> 2018年11月27日(火) 16:55 Jim Manico <[e-mail]>:
>>>> Nat,
>>>> 
>>>> How is proof of possession established in a modern web browser in the implicit flow?
>>>> 
>>>> My understanding is that token binding was removed from Chrome recently effectively killing browser-based PoP tokens.
>>>> 
>>>> https://identiverse.com/2018/10/31/chrome-puts-token-binding-in-a-bind/
>>>> 
>>>> Am I missing something?
>>>> 
>>>> Aloha, Jim
>>>> 
>>>> 
>>>> 
>>>>> On 11/27/18 9:00 PM, Nat Sakimura wrote:
>>>>> I am actually -1.
>>>>> 
>>>>> +1 for public client and the tokens that are not sender/key constrained.
>>>>> 
>>>>> Just not being used right now does not mean that it is not useful.. In fact, I see it coming.
>>>>> Implicit (well, Hybrid “token id_token” really) is very useful in certain cases.
>>>>> Specifically, when the client is confidential (based on public key pair), and uses sender constrained (key-constrained) token such as the one explained in https://tools.ietf.org/html/draft-sakimura-oauth-jpop-04#section-5, it is very useful.
>>>>> (Key-constrained token is the remaining portion of this draft that did not get incorporated in the MTLS draft. )
>>>>> In fact it is the only viable method for Self-Issued OpenID Provider.
>>>>> 
>>>>> So, the text is generally good but it needs to be constrained like “Unless the client is confidential and the access token issued is key constrained, ... “
>>>>> 
>>>>> Best,
>>>>> 
>>>>> Nat Sakimura
>>>>> 
>>>>> 
>>>>> 2018年11月27日(火) 16:01 Vladimir Dzhuvinov <[e-mail]>:
>>>>> +1 to recommend the deprecation of implicit.
>>>>> 
>>>>> I don't see a compelling reason to keep implicit when there is an
>>>>> established alternative that is more secure.
>>>>> 
>>>>> Our duty as WG is to give developers the best and most sensible practice.
>>>>> 
>>>>> CORS adoption is currently at 94% according to
>>>>> https://caniuse.com/#feat=cors
>>>>> 
>>>>> Vladimir
>>>>> 
>>>>> 
>>>>> _______________________________________________
>>>>> OAuth mailing list
>>>>> [e-mail]
>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>> -- 
>>>>> Nat Sakimura (=nat)
>>>>> Chairman, OpenID Foundation
>>>>> http://nat..sakimura.org/
>>>>> @_nat_en
>>>>> 
>>>>> 
>>>>> _______________________________________________
>>>>> OAuth mailing list
>>>>> 
>>>>> [e-mail]
>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>> -- 
>>>> Jim Manico
>>>> Manicode Security
>>>> 
>>>> https://www.manicode.com
>>>> -- 
>>>> Nat Sakimura (=nat)
>>>> Chairman, OpenID Foundation
>>>> http://nat.sakimura.org/
>>>> @_nat_en
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/oauth
>>> _______________________________________________
>>> Openid-specs-ab mailing list
>>> [e-mail]
>>> http://lists.openid.net/mailman/listinfo/openid-specs-ab