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

[Nat Sakimura <[e-mail]>]

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