mezzio-authentication-oauth2
mezzio-authentication-oauth2 copied to clipboard
mezzio
Client Secret and Client Redirect Url is mandatory
- [x] I was not able to find an open or closed issue matching what I'm seeing.
- [x] This is not a question. (Questions should be asked on slack (Signup for Slack here) or our forums.)
Provide a narrative description of what you are trying to accomplish.
For trusted apps or front-end only apps, client_secret and redirect_url is pretty silly. We should find a way to make these optional.
Originally posted by @wshafer at https://github.com/zendframework/zend-expressive-authentication-oauth2/issues/24
redirect_url should be optional but client_secret is not optional.
Originally posted by @TomHAnderson at https://github.com/zendframework/zend-expressive-authentication-oauth2/issues/24#issuecomment-373134027
Client secret doesn't make sense for single page apps. It's not much of secret if the client is passing it back and forth. This is only a real problem for the password grant.
Originally posted by @wshafer at https://github.com/zendframework/zend-expressive-authentication-oauth2/issues/24#issuecomment-373139686
You're not going to use the client secret for an implicit grant but you should not have a client without a secret. Maybe you can think of a client_credentials grant opening the client to anything? That won't be the best example but a secret is always better than no secret.
Originally posted by @TomHAnderson at https://github.com/zendframework/zend-expressive-authentication-oauth2/issues/24#issuecomment-373143793
Oh I see what you're saying. I don't mind having the client have to have a secret in the DB, but it should be optional on the password grant.
Originally posted by @wshafer at https://github.com/zendframework/zend-expressive-authentication-oauth2/issues/24#issuecomment-373158681
That used to be the case in zfcampus/zf-oauth2 and they changed it so the secret is required and I think that was the right decision.
Originally posted by @TomHAnderson at https://github.com/zendframework/zend-expressive-authentication-oauth2/issues/24#issuecomment-373168775
Hmm... so password grant will always include a not-so secret-secret? But that means I need to also disable the client grant, which is hard coded right now?
I guess you could use the implict grant as I think that's what that one was designed for, but there's not a way to put in your password auth in it's current form. So we still have problems with single page apps with this package.
Originally posted by @wshafer at https://github.com/zendframework/zend-expressive-authentication-oauth2/issues/24#issuecomment-373174388
@wshafer you're lamenting OAuth1 vs OAuth2 security. OAuth2 requires https. Also, you can and should send the client credentials in the Authorization: Basic header.
Implicit grant type does not require a secret, ever.
Originally posted by @TomHAnderson at https://github.com/zendframework/zend-expressive-authentication-oauth2/issues/24#issuecomment-373255170
https does not hide the secret from the browser in this case and only protects from man in the middle. Implicit Grant looks more what I would need for this instance, but that grant does not in it's current form allow me to send a user to the authentication or login system, and as far as I can tell, neither does the Authentication grant. We'd need to fix that and I'd be happy to close this issue. ;)
Originally posted by @wshafer at https://github.com/zendframework/zend-expressive-authentication-oauth2/issues/24#issuecomment-373418377
Actually now that I'm thinking about this, implicit grant isn't right either. However I'm willing to concede the client-secret issue, provided we add allowed grant types to the client entity. If I use the client-secret on a single page app, I need to disable all but password grant to that particular client. If I could do that, then the client-secret is a non-issue.
Originally posted by @wshafer at https://github.com/zendframework/zend-expressive-authentication-oauth2/issues/24#issuecomment-373433206