CORS - OPTIONS request blocked on userinfo request

[happy-dev]

Hi guys,

Thank you for this great application. It saved us a lot of time.

If the client app is not served by the same server as our Django OIDC provider, the OPTIONS request triggered by the browser on the /openid/userinfo URL fails for three reasons :

• because the OPTIONS HTTP verb is blocked by the application
• because the Authorization header is not sent to the server in the OPTIONS preflight
• because the Authorization header is not whitelisted in the Access-Control-Allow-Headers

We coded a workaround on our side, but wanted to let you know of the problem.
I would be surprised to be the first facing it.

If you have a recommanded solution, I would be happy to implement it.

All the best !

[juanifioren]

Hi @happy-dev, nice to hear this lib helps you.

The spec says:

The Client sends the UserInfo Request using either HTTP GET or HTTP POST.

So we can't add OPTIONS to the userinfo endpoint. If we add Access-Control-Allow-Origin: * header, django will be still blocking the request.

I'll check what others frameworks are doing with this.

[q3aiml]

@juanifioren The spec also states:

The UserInfo Endpoint SHOULD support the use of Cross Origin Resource Sharing (CORS) [CORS] and or other methods as appropriate to enable Java Script Clients to access the endpoint.

Supporting OPTIONS is part of supporting CORS: https://www.w3.org/TR/access-control/. The preflight OPTIONS request is a side effect of a GET or POST request issued by the client. The OPTIONS implementation only needs to return the relevant headers -- it does not need to carry out the full userinfo request or return the standard response body.

[happy-dev]

@juanifioren : Thanks for your response

@q3aiml : Exactly. I think you understood perfectly

[thebjorn]

I would be surprised to be the first facing it.

You're not. We ran head first into this issue as well (trying to do an ajax call to a 3rd party that authenticates against us..). We've punted on it for the time being so I'm very happy there is a solution.

[juanifioren]

to be released on next version

[defgsus]

Thanks for your fix @q3aiml,
still the OPTIONS request is blocked by the protected_resource_view decorator.
I know, the openid-connect-core spec does not mention OPTIONS. But it seems to be used and accepted around. For example redux-oidc uses it, and actually fails authenticating through django-oidc-provider. It works through auth0.com as provider as they return the headers for OPTIONS without the access token.
I suggest adding a unprotected_methods parameter to the protected_resource_view decorator, which would make it possible to let OPTIONS requests pass.

[defgsus]

Opened a new issue for the blocking thing #304