Closed nvanheuverzwijn closed 4 years ago
Merging #926 into master will not change coverage. The diff coverage is
100%
.
@@ Coverage Diff @@
## master #926 +/- ##
=======================================
Coverage 88.91% 88.91%
=======================================
Files 137 137
Lines 3734 3734
=======================================
Hits 3320 3320
Misses 414 414
Impacted Files | Coverage Δ | |
---|---|---|
...ib/policies/oauth2-introspect/oauth2-introspect.js | 100% <100%> (ø) |
:arrow_up: |
Continue to review full report at Codecov.
Legend - Click here to learn more
Δ = absolute <relative> (impact)
,ø = not affected
,? = missing data
Powered by Codecov. Last update 1f29dca...778bdc0. Read the comment docs.
@nvanheuverzwijn Hey,
Thanks a lot for this — apparently this makes sense but I'll need to dig down in the documents one more time. I recall we went with scopes
because of the official document or something, but I can't really find it right now.
@XVincentX Gotcha, no problem. Thanks !
As per https://www.iana.org/assignments/jwt/jwt.xhtml, the currently standard way of defining scopes is through the
scope
key and notscopes
. In this documentscope
is currently draft which cast some confusion on wheter or not it is standard.See https://datatracker.ietf.org/doc/draft-ietf-oauth-token-exchange/?include_text=1
RFC7662 define
scope
as the key defining scopes in the introspection response which reinforce the idea thatscope
is more standard thanscopes
. See https://tools.ietf.org/html/rfc7662 section 2.2Which brings us to RFC6749 (the oauth2 rfc) which define
scope
as the authorization response. See https://tools.ietf.org/html/rfc6749 section 4.1.1In my opinion, we should keep the
scopes
for backward compatibility unless you know no one is using oauth-introspection. We could also add the ability to specify the "scope" key in the parameters of the plugins and encourage users to usescope
instead ofscopes
.What do you think ?