Since that is my comment referenced in the OpenID thread, I should clarify that my intent was to have this language in the Security BCP with the caveat that it's only applicable if your AS intends on supporting SPAs. In other words, we're not saying all ASs SHOULD add CORS headers, only ASs that intend on supporting SPAs. However, even if the AS does not intend on supporting SPAs, it still MUST NOT enable CORS at the authorization endpoint.
I don't know the best language to put in front of Mike's suggested text to make that clear, so suggestions are welcome. Aaron On Tue, Mar 7, 2023 at 11:16 PM Mike Jones <Michael.Jones= 40microsoft....@dmarc.ietf.org> wrote: > I propose adding the following section to the OAuth Security BCP > specification: > > > > *Usage of CORS* > > > > The Token Endpoint, > > Authorization Server Metadata Endpoint, > > <spanx style="verb">jwks_uri</spanx> Endpoint, > > Dynamic Client Registration Endpoint, > > and any other endpoints directly accessed by Clients > > SHOULD support the use of > > <xref target="CORS">Cross-Origin Resource Sharing > (CORS)</xref> > > to enable JavaScript Clients and other browser-based Clients > to access them. > > CORS MUST NOT be used at the Authorization Endpoint > > as it is redirected to by the client and not directly > accessed. > > > > > > Relevant background information can be found at > https://bitbucket.org/openid/connect/issues/980 and > https://bitbucket.org/openid/connect/pull-requests/338/errata-specified-the-use-of-cors-at > . > > > > -- Mike > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
