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

Nat Sakimura sakimura at gmail.com
Tue Nov 27 15:57:57 UTC 2018


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 listOAuth at ietf.orghttps://www.ietf.org/mailman/listinfo/oauth
>
> --
> Jim Manico
> Manicode Securityhttps://www.manicode.com
>
> --
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20181127/a748ac21/attachment.html>


More information about the Openid-specs-ab mailing list