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

Torsten Lodderstedt torsten at lodderstedt.net
Tue Nov 27 19:30:45 UTC 2018


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 <sakimura at gmail.com>:
> 
> 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 <jim at manicode.com>:
> 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 <vladimir at connect2id.com>:
>> +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
>> OAuth at ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>> -- 
>> Nat Sakimura (=nat)
>> Chairman, OpenID Foundation
>> http://nat..sakimura.org/
>> @_nat_en
>> 
>> 
>> _______________________________________________
>> OAuth mailing list
>> 
>> OAuth at ietf.org
>> 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
> OAuth at ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3892 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20181127/a6e900ec/attachment-0001.p7s>


More information about the Openid-specs-ab mailing list