Implement OAuth2 password flow#2397
Conversation
|
@bodnia can you review? |
|
@MugeSo at least, client_id is necessary for password grant_type request at OAuth2. Right now, Your update is not sending any client information. |
|
MugeSo#1 I sent you an pr. |
|
@hkulekci I cannot find what you say though I read RFC6749 again. |
|
And there is no spec about oauth2 client authentication in Open API specification. |
|
@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. |
|
@hkulekci Ok, I see what you want. And it also solves #2183. @webron @fehguy Which do you prefers implement client authentication in this PR or as another PR? |
|
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:
Helped me to make flow works and tests oauth2 provider properly. |
|
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? |
|
I too am eagerly watching this PR, this is going to fix so many workarounds we had to implement. |
|
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. |
|
@MugeSo @hkulekci The RFC doesn't say a word about |
|
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. |
|
Actually, the section 3.2.1 states the following:
It seems to me that the reason why |
|
I've implemented client authentication for password and application flow, because some libraries requires it as you say. |
|
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! |
|
@MugeSo Is there and should be there a way to set a default |
|
@frol What is a "default" which you say? |
|
@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. |
|
UPDATE: UPDATE2: |
|
@bodnia any update on the issue? It seems more people have chipped and got it working? |
|
Hi folks, we could really do with this support as well. Was a solution found? Anything I can do to help? |
|
@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). |
|
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-examplehttp://127.0.0.1:5000/api/v1/ (login: |
297eb12 to
3494d44
Compare
|
@frol Thank you for mention. I resolved it :) |
| scopes: {} | ||
| scopes: {}, | ||
| isPasswordFlow: false, | ||
| clientAuthenticationType: 'none' |
There was a problem hiding this comment.
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'); |
There was a problem hiding this comment.
It seems to me that clientAuthentication should be available in every OAuth2 Flow.
There was a problem hiding this comment.
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!!
|
@bodnia any update on the issue? It seems more people have chipped and got it working? |
|
Any joy with this folks? Is this functionality available in master now or am I getting ahead of myself? |
|
Please merge this guys, I am waiting for this fix for a long time :) |
|
+1 |
|
@webron I tested, and this works ok and can be merged |
|
Thanks for all the work and tweaks, @MugeSo - glad to see such a contribution to the project. |
|
WOW! Supercalifragilisticexpialidocious! |
|
woow. Finally merged. Thank you. |
|
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? |
This PR is an OAuth2 password flow implementation works with #2014
This PR updates #1853 and #1574
And this closes #807