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

[Torsten Lodderstedt <[e-mail]>]

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