[Openid-specs-ab] [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit
sakimura at gmail.com
Tue Nov 27 15:30:35 UTC 2018
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
Specifically, when the client is confidential (based on public key pair),
and uses sender constrained (key-constrained) token such as the one
https://tools.ietf.org/html/draft-sakimura-oauth-jpop-04#section-5, it is
(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,
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
> OAuth mailing list
> OAuth at ietf.org
Nat Sakimura (=nat)
Chairman, OpenID Foundation
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Openid-specs-ab