I'm trying to work out if our OAuth server is missing a grant or whether this is incorrect use of the grant.
The password flow in the authorize step with basic auth seems to curl 'https://api.domain.com/oauth2/token' -H 'authorization: Basic dXNlcm5hbWU6cGFzc3dvcmQ=' -H 'content-type: application/x-www-form-urlencoded' -H 'access-control-allow-origin: *' -H 'accept: application/json, text/plain, */*' --data 'grant_type=password
Where the basic auth contains the username/password of the user. However I can't find this in the RFC. Should this not contain the user/pass in the body with the client_id/secret in the the basic auth header?
Having done further research it seems that the client_id/secret should be in the basic auth and the password/username should be in the request body as per: https://tools.ietf.org/html/rfc6749#page-39
@bodnia can you look into this issue please?
This change was made by request in https://github.com/swagger-api/swagger-ui/issues/3128
And now client_id and client_secret are in header, and username/password - in body, these changes are in master
Here is PR https://github.com/swagger-api/swagger-ui/pull/3155/files
@benoj is this something you're looking for?
Here is my thorough summary of the state of OAuth2 Password Flow implementation in Swagger-UI: #3227.
Hi,
I'm not sure if this is related to the above bug but I'll describe my problem here anyway:
I try to use oauth2 password flow. But additionally our /oauth/token endpoint is protected by basic auth. So I tried the oauth2 password flow and selected basic auth from the authorize popup window. Now there is first an OPTIONS call made to the /oauth/token endpoint, but I cannot see any authorize header. So I receive 403 forbidden and cannot continue. I tried to find the place in the code where this OPTIONS call is made myself but couldn't find it 馃槥
Is this a bug or how is this supposed to work? Thanks!

@matzetronic First of all, you are looking at the OPTIONS request, which is part of CORS, so it is not the authentication request, take a look at the next (POST) request in the dev tools.
In any case, the basic auth in the OAuth2 dialog should correspond to the OAuth2 scheme where Authorization header is used for OAuth2 protocol parameters (client_id / client_secret), though the implementation is "different" (#3227).
Also, I don't believe Swagger UI (and Swagger Codegen) can apply several authentication settings at once, and I don't think this makes a lot of sense to have layered authentications, but that is up to you, really (though, most probably, you will be on your own with the implementation of such a thing).
Since I'm not an expert with oauth and security I don't know if that makes sense or not. I'm just stuck since I can't get it to work. By the way, my token endpoint is https://docs.cloudfoundry.org/api/uaa/#with-authorization so I don't think I will be the only one with that problem in the future..
By the way, my token endpoint is https://docs.cloudfoundry.org/api/uaa/#with-authorization so I don't think I will be the only one with that problem in the future.
The link describes a well-implemented OAuth2 endpoint. OAuth2 should be (yet it is partially broken in 3.x) implemented in Swagger UI. The thing that is not implemented (and I don't feel like it should be implemented ever) is the "But additionally our /oauth/token endpoint is protected by basic auth".
The thing that is not implemented (and I don't feel like it should be implemented ever) is the "But additionally our /oauth/token endpoint is protected by basic auth".
But isn't that exactly what https://docs.cloudfoundry.org/api/uaa/#with-authorization describes?
Nope. "With authorization" is just a variant of possible OAuth2 implementation where client_id and client_secret are passed via Authorization header instead of POST parameters (see the "without authorization" example). Unfortunately, 3.x broke all the Password Flow variants of OAuth2 except "without authorization" (passing the client credentials via POST parameters) - #3227
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.
I'm also stuck like @matzetronic , why it sends OPTIONS and now authorization header?
Please check my description here how it should be: https://github.com/swagger-api/swagger-ui/issues/3227#issuecomment-372113801
Locking due to inactivity.
This is done to avoid resurrecting old issues and bumping long threads with new, possibly unrelated content.
If you think you're experiencing something similar to what you've found here: please open a new issue, follow the template, and reference this issue in your report.
Thanks!