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

Removed need for clientSecret for some grant types #530

Closed
wants to merge 1 commit into from
Closed

Removed need for clientSecret for some grant types #530

wants to merge 1 commit into from

Conversation

mvdstam
Copy link
Contributor

@mvdstam mvdstam commented Aug 21, 2015

The client_secret shouldn't be necessary when using the password or refresh_token grant types.
In the former (in cases where client secrets cannot be stored securely), security is handled on a resource owner level, where users in a (for example) mobile web application can login to an application using their own credentials.
In the latter, the new access tokens are retrieved using special "refresh tokens", which are sent back as a part of the regular OAuth2.0 response body when a client has successfully authenticated with some kind of grant_type. Asking the client for a client_secret again is unnecessary in my opinion.

To create a bit of context for this PR: I've been using this package (with this proposed change) in a mobile webapplication, where resource owners authenticate once (by simply logging in using their email address and password using the password grant) and then just (statelessly) identify themselves using their OAuth2.0 access token. Should the token expire, the client application then simply requests to refresh the token using the refresh_token grant. The whole setup consists of an front-end webapplication and a back-end http://jsonapi.org server, where the communication is done by XHR (with CORS). In all OAuth-related requests, only the client_id is sent back to the server.

Thoughts?

@lucadegasperi
Copy link
Owner

Add an intermediate layer that can safely store your client credentials in your application and that acts like a proxy to the api server. http://alexbilbie.com/2014/11/oauth-and-javascript/
This package is focused on security, in fact most of the recommendations found in the OAuth2 are implemented here. Making some security parameters optional would mean less secure APIs will spread across the internet.

@mvdstam
Copy link
Contributor Author

mvdstam commented Aug 24, 2015

Alright, fair enough. Are there any plans to implement the JWT grant for this package, so I can implement OAuth 2.0 on web-based clients the "correct" way?

@vinkla
Copy link
Collaborator

vinkla commented Aug 24, 2015

We'll start looking at JWT support once it has been added to the oauth2-server package. In the meantime you can check out this package by @tymondesigns.

@mvdstam
Copy link
Contributor Author

mvdstam commented Aug 25, 2015

Thank you, @vinkla. I'll look into that and hope to see JWT support added soon. 😄

@pashamesh
Copy link

There is setRequireClientSecret method for RefreshTokenGrant already:
https://github.com/thephpleague/oauth2-server/blob/master/src/Grant/RefreshTokenGrant.php#L94

all needed to implement unnecessary client_secret is to add something like:

if (array_key_exists('require_client_secret', $grantParams)) {
    $grant->setRefreshTokenRotation($grantParams['require_client_secret']);
}

to the foreach in boot method of OAuth2ServerServiceProvider.php

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