rfc6749 + CORS + OAuth

[micjaesc]

My token's provider doesn't support CORS, and he argues with sentence from rfc6749 The client MUST use the HTTP "POST" method when making access token
In other hands, it is difficult for me to understand how to use swagger UI without CORS & different domains

So... did I miss something? Did I use swagger in wrong way? My understanding of OAuth is wrong... or my token's provider has weak argument?
Thank you for any comments, whole my swagger setup will be useless without authorization.

[shockey]

Hi @micjaesc, OAuth and RFC6749 aside - almost any cross-domain request that any application in a browser makes requires CORS headers. You won't be able to talk to your authorization server at all without that enabled on the server side.

[micjaesc]

if CORS support is missed by my token provider, then what is your opinion for such strict argue of RFC6749: The client MUST use the HTTP "POST" method when making access token. Token Provider is fully compatible with RFC6749 in that aspect or.... he has just over interpreted.

[shockey]

@micjaesc, I'm not sure what you're getting at - we always send POST requests for tokens. Are you seeing something different?

[hkosova]

@micjaesc see if this or this helps.

[micjaesc]

@shockey , before POST, the OPTIONS is sent (because of CORS). OPTIONS is not support by my token provider, and my question here, who interpret wrongly RFC6749. Swagger who uses token issuing on front, or my token provider who doesn't support CORS, because he sticks to sentence The client MUST use the HTTP "POST" method when making access token Meantime, I will try to disable it by @hkosova 's tip

[micjaesc]

chrome-extensions support response_header overwriting, but not final HTTP status code (which is now 400). Using CORS proxy (like http://crossorigin.me) is not a option for us. Hmmm..

[shockey]

@micjaesc, it seems to me that your token provider is wrong.

CORS is an additional browser security mechanism that exists outside of OAuth's request flow.

When Swagger UI (or any web application) wants to talk to a cross-domain server, the user's browser puts that request on hold and sends out a preflight request that asks the server for security rules about what web pages are allowed to send requests to it - that's the OPTIONS request that you're seeing.

Once the OPTIONS request is handled correctly (sending back 200 OK and setting the correct Access-Control response headers), the browser will allow the OAuth POST request to proceed.

Doing so doesn't break OAuth's rules - the POST request is there as it should be, it's just that the token server needs to do more since browser security rules are involved.

[shockey]

Closing due to inactivity.

This is simply to keep our issue tracker clean - feel free to comment if there are any further thoughts or concerns, and we'll be happy to reopen this issue.

[t1gr4n]

I just run to the same issue today.
@shockey, the token provider is not wrong, it seems to me they are totally right. See, the application flow is not intended to be used from browser, and the token provider is actually fully compatible with the RFC. What is wrong here is that the swagger is making the request from the browser, but that request never intended to be done from browser, it had to be done from the backend. So, to correctly support OAuth2 application flow in swagger, the frontend part need to make a all to the backend handler, which on its turn should initiate a call to the token provider.
Apart from the CORS, there are other use cases as well, which would not work: for example, if the token provider is accessible from the server that hosts the application/API, but is not accessible from the client machine that runs the browser (but, of course, the backend server is accessible from the client machine).
This is either bug or a design issue, and should be fixed.

[jstallm]

the application flow is not intended to be used from browser,

"the application flow is not intended to be used from browser," @t1gr4n Do you have any documentation to support this claim?