> Additionally stating that unique audiences shall be used for different services should be ok. Fair! I'll add language to that effect in section 5 and update the draft before Friday. thanks! V.
On Mon, Jul 22, 2019 at 9:25 AM Torsten Lodderstedt <[email protected]> wrote: > > > > On 22. Jul 2019, at 17:13, Vittorio Bertocci < > [email protected]> wrote: > > > > Thank you Torsten for the prompt review and insightful comments! > > > > 2.2.1 - excellent point. I added the suggested language. > > > > 2.2.2 - interesting. I did think of cases similar to profile in OIDC, > where the effect of the request is influencing the layout of the resulting > idtoken, but concluded that it didn't apply as is for access tokens. Given > that you have direct knowledge of such cases in the wild, I am happy to > relax the MUST into a SHOULD. > > > > 5. - this is going to be problematic in the wild. For example, in the > azure AD world a registered application can play both the role of an API > and a client; and requests for tokens targeting the app can use any > identifier assigned to the app. That means that although idtokens will only > be issued if the request identifies the client via clientID, access tokens > requests for it will be honored (and reflected in aud) both in the case the > resource parameter contains the clientID or the API URI of the target > application. > > Interesting and (in my opinion) reasonable. Out of the top of my head I > don’t see how this has a negative security impact since the recipient is > always the same service. > > > In fact I suspect that the most recent version of the service uses the > clientID as preferred identifier, if not the only one. Mike/Tony can > confirm or deny. > > As a compromise, we could add language in the spec that recommends the > use of a unique audience when viable, as an extra measure in case the typ > value isn't honored. WDYT? > > Having a unique audiences at least for different services is key. > > In fact, I’m concerned about JWT confusion in OIDC RPs in the wild that do > generally not honor the type (as long as we do not update OIDC Core to > require this and it is being adopted). I think since your draft requires > both, iss and aud to be present, this threat is being dealt with. > Additionally stating that unique audiences shall be used for different > services should be ok. > > > > > > > > On Mon, Jul 22, 2019 at 7:01 AM Torsten Lodderstedt < > [email protected]> wrote: > > Hi Vittorio, > > > > thanks for contributing this specification. It fills a further gap in > the OAuth universe :-) > > > > Here are my comments: > > > > - 2.2.1 there are other sources for identity claims, e.g. > https://openid.net/specs/openid-connect-4-identity-assurance-1_0.html. > > > > I recommend to open the clause > > > > "Any additional attributes whose semantic is well described by the > > attributes description found in section 5.1 of [ > > OpenID.Core] SHOULD > > be codified in JWT access tokens via the corresponding claim names in > > that section of the OpenID Connect specification. The same holds for > > attributes defined in [RFC7662]." > > > > by adding > > > > "and other identity related specifications.” > > > > Alternatively, the draft could also refer to the IANA “OAuth Token > Introspection Response” registry as source for JWT claims. > > > > - 2.2.2. > > > > "If an authorization request includes a scope parameter, the > > corresponding issued JWT access token MUST include a scope claim as > > defined in section 4.2 of [TokenExchange]." > > > > Why do you establish such a strong link between the scope in the > authorization request and the access token? I’m aware of implementations > that map scope values to audience values and therefore do not carry the > scope value to the resource server. I suggest to soften this requirement > and make it a recommendation. > > > > - 5. > > > > "The JWT access token data layout described here is very similar to the > one of the id_token as defined by [OpenID.Core]. Without the > > explicit typing required in this profile, in line with the > recommendations in [JWT.BestPractices] there would be the risk of > > attackers using JWT access tokens in lieu of id_tokens." > > > > I like this practice but it is not established yet in the OpenID Connect > universe. This means any OIDC RP will process an access token because it > will just ignore the type header. > > > > draft-ietf-oauth-jwt-introspection-response therefore gives > recommendation on how to use iss and aud claim to prevent JWT abuse ( > https://tools.ietf.org/html/draft-ietf-oauth-jwt-introspection-response-04#section-6.1). > > > > > Mapping this pattern to JWTs as access token requires that there must > not be the same aud value for a resource server and any other JWT consumer, > e.g. an OpenID Connect RP. > > > > kind regards, > > Torsten. > > > > > On 21. Jul 2019, at 14:55, [email protected] wrote: > > > > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > This draft is a work item of the Web Authorization Protocol WG of the > IETF. > > > > > > Title : JSON Web Token (JWT) Profile for OAuth 2.0 > Access Tokens > > > Author : Vittorio Bertocci > > > Filename : draft-ietf-oauth-access-token-jwt-01.txt > > > Pages : 15 > > > Date : 2019-07-20 > > > > > > Abstract: > > > This specification defines a profile for issuing OAuth2 access tokens > > > in JSON web token (JWT) format. Authorization servers and resource > > > servers from different vendors can leverage this profile to issue and > > > consume access tokens in interoperable manner. > > > > > > > > > The IETF datatracker status page for this draft is: > > > https://datatracker.ietf.org/doc/draft-ietf-oauth-access-token-jwt/ > > > > > > There are also htmlized versions available at: > > > https://tools.ietf.org/html/draft-ietf-oauth-access-token-jwt-01 > > > > https://datatracker.ietf.org/doc/html/draft-ietf-oauth-access-token-jwt-01 > > > > > > A diff from the previous version is available at: > > > https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-access-token-jwt-01 > > > > > > > > > Please note that it may take a couple of minutes from the time of > submission > > > until the htmlized version and diff are available at tools.ietf.org. > > > > > > Internet-Drafts are also available by anonymous FTP at: > > > ftp://ftp.ietf.org/internet-drafts/ > > > > > > _______________________________________________ > > > OAuth mailing list > > > [email protected] > > > https://www.ietf.org/mailman/listinfo/oauth > > > >
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
