Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Implement OAuth2 password flow #2397

Merged
merged 3 commits into from
Dec 6, 2016

Conversation

MugeSo
Copy link
Contributor

@MugeSo MugeSo commented Sep 10, 2016

This PR is an OAuth2 password flow implementation works with #2014

This PR updates #1853 and #1574
And this closes #807

@webron
Copy link
Contributor

webron commented Sep 14, 2016

@bodnia can you review?

@hkulekci
Copy link

@MugeSo at least, client_id is necessary for password grant_type request at OAuth2. Right now, Your update is not sending any client information.

@hkulekci
Copy link

MugeSo#1 I sent you an pr.

@MugeSo
Copy link
Contributor Author

MugeSo commented Sep 20, 2016

@hkulekci I cannot find what you say though I read RFC6749 again.
I found only descriptions which says that clinent_id is required for client password authentication(for client authentication), authorization code grant or implicit grant.
And password grant does not requires client authentication. it just optional.

@MugeSo
Copy link
Contributor Author

MugeSo commented Sep 20, 2016

And there is no spec about oauth2 client authentication in Open API specification.
So I sent issue OAI/OpenAPI-Specification#785.

@hkulekci
Copy link

hkulekci commented Sep 20, 2016

@MugeSo you are right. RFC don't force. But I don't understand how the api understand the people come which client in this scenario.

To be able to work this scenario, we must take a client token before sending a request for a password credential request.

Update: I am using https://oauth2.thephpleague.com/authorization-server/resource-owner-password-credentials-grant/ this library. And client_id is required for Password Grant Type request.

@MugeSo
Copy link
Contributor Author

MugeSo commented Sep 20, 2016

@hkulekci Ok, I see what you want.
I think we need to implement client authentication correctly, to solve your problem.

And it also solves #2183.

@webron @fehguy Which do you prefers implement client authentication in this PR or as another PR?

@HugoMario
Copy link

I edited the PR (still not check in) in order to test this flow with the sample oauth2 provider that it's being developed. Adding next headers:

var requestHeaders = { 'Authorization': 'Basic ' + btoa(username + ':' + password), 'Content-Type': 'application/x-www-form-urlencoded' };

$.ajax({ ... headers: requestHeaders, ...

Helped me to make flow works and tests oauth2 provider properly.

@wimpers
Copy link

wimpers commented Oct 31, 2016

It seems that the milestone to which #807 belongs is closed. Does this mean that the issue is fixed (I assume not as it is still open) or will this PR be merged in a newer version?

@pndv
Copy link

pndv commented Nov 1, 2016

I too am eagerly watching this PR, this is going to fix so many workarounds we had to implement.

@wimpers
Copy link

wimpers commented Nov 4, 2016

@fehguy , @bodnia I know you guys must be super busy but could it be that this one wasn't merged in v2.1.4 (#807) ? Can it be merged into the latest version?

@bundabrg
Copy link

bundabrg commented Nov 7, 2016

Could not client_id and client_secret be optional parameters asked on the same dialogue as the username/password? That's how I'm implementing it and is far closer to how a real client will work. Saves having to hard-code it in.

@frol
Copy link

frol commented Nov 9, 2016

@fehguy @bodnia @webron Can we hear at least a word from you? There were already two PRs (#1574, #1853) which got outdated just because of the project refactoring. I don't want to see this one become outdated once again. I beg you to merge it while it has no conflicts.

@bodnia
Copy link
Contributor

bodnia commented Nov 9, 2016

@wimpers @bundabrg @frol I'll look into it by Monday EOD, sorry for delays.

@frol
Copy link

frol commented Nov 11, 2016

@MugeSo @hkulekci The RFC doesn't say a word about client_id and client_secret for Resource Owner Password Credentials Grant, but the example in section (4.3.2) indicates the Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW header, which is the base64(cliend_id:client_secret) just like @HugoMario implemented.

@bundabrg
Copy link

Actually I'm pretty confused here. The RFC doesn't state anything about client_id or client_secret for a Resource Owner Password Credentials Grant. Yet nearly every other page I've researched about OAuth2 grants described this grant with client_id and client_secret as part of the exchange, including oauthlib requiring it.

@frol
Copy link

frol commented Nov 12, 2016

Actually, the section 3.2.1 states the following:

Confidential clients or other clients issued client credentials MUST authenticate with the authorization server as described in Section 2.3 when making requests to the token endpoint.

It seems to me that the reason why client_id is specifically mentioned in some of the flows is that the headers cannot be easily set for those requests (e.g. if you want to perform OAuth2 in pure HTML (without JS) you will only need to define a form with a "hidden" client_id field).

@MugeSo
Copy link
Contributor Author

MugeSo commented Nov 12, 2016

I've implemented client authentication for password and application flow, because some libraries requires it as you say.

@frol
Copy link

frol commented Nov 12, 2016

I have just tested the latest changes and both "Basic auth" and "Request body" work for me on my Flask-Oauthlib based OAuth2 server!

@MugeSo Great job!

@frol
Copy link

frol commented Nov 12, 2016

@MugeSo Is there and should be there a way to set a default client_id?

@MugeSo
Copy link
Contributor Author

MugeSo commented Nov 13, 2016

@frol What is a "default" which you say?
Is it the global variable clientId defined in lib/swagger-oauth.js?

@frol
Copy link

frol commented Nov 13, 2016

@MugeSo It used to be it, but since that code seems to be dead and mostly useless, I wouldn't mind if the way to configure the defaults gets changed.

@frol
Copy link

frol commented Nov 13, 2016

Hmm, I am not sure what is the origin of the problems, so it might be out of the scope of this issue, but let me put them here:

  1. The checkbox selection of the scopes is ignored, clicking the "Authorize" button always results in sending out all available scopes. Selected OAuth2 scopes are not respected on authentication #2497
  2. When I added <div id="auth_container"></div> container to have a top-level "Authorize" button (like on the top bar here: http://petstore.swagger.io/), the listed scopes include a "vendorExtensions - [object Object]" scope at the end of the scopes list. (I don't experience this issue on the demo site passing my swagger.json there.) OAuth2 request adds vendorExtension scope to all auth requests #2483

@MugeSo Do you have any guesses?

UPDATE: I have found the reported issue #2483 describing exactly what I experience in (2). Fixed.

UPDATE2: It turned out that the behaviour I experienced in (1) is also a general Swagger-UI bug, so I reported it here #2497. Fixed.

@wimpers
Copy link

wimpers commented Nov 18, 2016

@bodnia any update on the issue? It seems more people have chipped and got it working?

@danballance
Copy link

Hi folks, we could really do with this support as well. Was a solution found? Anything I can do to help?

@frol
Copy link

frol commented Nov 22, 2016

@danballance I think you may try and test it against your server (I have tested it against Flask-OAuthlib and everything works for me as far as I can tell, but it is always better to have an extra pair of eyes here, I guess).

@MugeSo @bodnia A conflict in AuthView.js appeared. :(

@frol
Copy link

frol commented Nov 22, 2016

By the way, there is a demo API server which bundles this patch rebased on top of a recent master branch: https://github.com/frol/flask-restplus-server-example. The demo is written in Python, but it is really easy to evaluate it if you use Docker:

$ docker run -it --rm --publish 5000:5000 frolvlad/flask-restplus-server-example

http://127.0.0.1:5000/api/v1/ (login: root, password: q)

@MugeSo MugeSo force-pushed the implement-oauth2-password-flow branch from 297eb12 to 3494d44 Compare November 24, 2016 08:36
@MugeSo
Copy link
Contributor Author

MugeSo commented Nov 24, 2016

@frol Thank you for mention. I resolved it :)

scopes: {}
scopes: {},
isPasswordFlow: false,
clientAuthenticationType: 'none'
Copy link

@frol frol Nov 24, 2016

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can this default be configurable? In fact, I would love to have it configured to be Basic by default as it is what the RFC describes.

var flow = this.attributes.flow;
this.set('isPasswordFlow', flow === 'password');
this.set('requireClientAuthentication', flow === 'application');
this.set('clientAuthentication', flow === 'password' || flow === 'application');
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It seems to me that clientAuthentication should be available in every OAuth2 Flow.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, it's advisable what you say.
But, this PR does not support client authentication for other flows.
I add client authentication just to make password flow usable.
I just want to merge password-flow implementation quickly!!

@wimpers
Copy link

wimpers commented Nov 29, 2016

@bodnia any update on the issue? It seems more people have chipped and got it working?

@danballance
Copy link

Any joy with this folks? Is this functionality available in master now or am I getting ahead of myself?

@pndv
Copy link

pndv commented Dec 5, 2016

Please merge this guys, I am waiting for this fix for a long time :)

@ncarlier
Copy link

ncarlier commented Dec 6, 2016

+1

@bodnia
Copy link
Contributor

bodnia commented Dec 6, 2016

@webron I tested, and this works ok and can be merged

@webron
Copy link
Contributor

webron commented Dec 6, 2016

Thanks for all the work and tweaks, @MugeSo - glad to see such a contribution to the project.

@webron webron merged commit 2ba1c10 into swagger-api:master Dec 6, 2016
@frol
Copy link

frol commented Dec 6, 2016

WOW! Supercalifragilisticexpialidocious!

@hkulekci
Copy link

hkulekci commented Dec 6, 2016

woow. Finally merged. Thank you.

@VenomAV
Copy link

VenomAV commented May 3, 2017

I do not know if this is the right place for this question: is there any way to specify default client_id and client_secret for password flow through Swagger UI configurations?

@bodnia
Copy link
Contributor

bodnia commented May 4, 2017

@VenomAV one of options is from #3010 and one more option is with configs, but not implemented yet

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Oauth2 password flow