> On Mar 9, 2023, at 1:57 AM, Vittorio Bertocci
> <Vittorio=40auth0....@dmarc.ietf.org> wrote:
>
> On CORS for the authorization endpoint. I thought the MUST NOT was aimed at
> preventing programmatic access to the authorization endpoint from user
> agents. Flipping around: are there any other scenarios involving the
> authorization endpoint for which CORS support enables valid use cases?
It is challenging because we typically overload a single endpoint with new
behavior, rather than create new ones for specific purposes. This gives odd
permutations, such as implementations which conditionally block frame
embedding, except when prompt=none. It also makes it very difficult to make
generalizations.
For the currently defined extensions that I know of, there is not a good reason
to enable CORS - rather, CORS would be harmful without additional security
requirements.
The clearest example of CORS interaction would be programmatically driving
authorization experience. I would argue user-facing content which is driving
authorization actually _is_ the authorization endpoint, and whatever API it is
interacting with (whether standardized or not) should not be exposed via the
authorization endpoint.
A second example would be to invoke an authorization decision programmatically
with out-of-band user interaction. The associated work with this sort of need
is CIBA, which defined a separate backchannel_authentication_endpoint.
-DW
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
