Where else do we need to specify the use of CORS support?

[Michael Jones]

While the UserInfo Endpoint specifies the use of CORS at http://openid.net/specs/openid-connect-standard-1_0-21.html#userinfo, we failed to do this for the Discovery endpoint and likely other relevant endpoints as well. What else did we leave out?

Without this, JavaScript clients won't work.

[Justin Richer]

In MITREid Connect, we have CORS enabled on:

• token endpoint
• JWK publishing enpdoint
• everything in .well-known (both configuration and webfinger)
• client registration endpoint (and management endpoints as we create them as sub-URLs of the registration endpoint)
• userinfo endpoint
• introspection endpoint
• revocation endpoint

There are a couple of others that are application-specific but these are the ones all defined by standards of some flavor in our implementation.

[Nov Matake]

Does "introspection endpoint" means what provided for resource servers? Then I don't think CORS is needed for the endpoint.

Otherwise, I agree Justin's list.

[Michael Jones]

Brian says that whether to CORS enable the token endpoint and registration endpoint are policy decisions. It's necessary if they are to be called from JavaScript.

The introspection and revocation endpoints don't appear in Connect, and so aren't relevant for the errata process.

[Mitar]

I think it is important to also document that CORS should not be enabled for authorization endpoint. If it is done, this can lead to enabling bad design: an SPA client which is configured as it is a confidential client.

[Michael Jones]

Will be fixed by https://bitbucket.org/openid/connect/pull-requests/338/errata-specified-the-use-of-cors-at

[Michael Jones]

The PR now says “The use of CORS at the Authorization Endpoint is NOT RECOMMENDED as it is redirected to by the client and not directly accessed.“ Does that work for people?

[Mitar]

I think this is fine, but is there a reason for not being MUST NOT use CORS on at the Authorization Endpoint?

[Michael Jones]

Adding a MUST NOT would be a normative spec change, which we should preferably not as an errata action.

Anyway, thanks for your diligence on this issue!

[Mitar]

Hm, you are right. Maybe MUST NOT would be more suitable for https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics?

[Michael Jones]

Adding it to the OAuth Security BCP is a great idea - since it’s really an OAuth issue in the first place.

[Michael Jones]

Addressed by https://bitbucket.org/openid/connect/pull-requests/338

[Aaron Parecki]

To me it seems like the OAuth Security BCP would be the right place to mention NOT adding CORS to the authorization endpoint, but the Browser Apps BCP would be the right place to add the full known list of endpoints that DO need CORS support.

CORS on the authorization endpoint is a security issue, CORS on the token and endpoints are a matter of whether the AS is usable at all by JS clients.

[Dmitry Telegin]

@aaronpk could you please elaborate on why CORS on the authorization endpoint would be a security issue? (not disputing, just want to understand this better)

FYI, Connect2ID does allow cross-origin fetch calls to authorization endpoint, but this is limited to prompt=none and their custom response_mode=cors.