Add support for public clients

[odbayar]

Not having public clients makes the bundle almost unusable for JavaScript or desktop based apps.

[ima-tech]

We really need to have public clients or be able to pass the client_secret via SESSION so that we can use it in Javascript apps.

[alanbem]

[...] javascript apps.

if you are talking about api-first apps then proxy api is a choice

[alanbem]

I will look into this in following week or two... I know that lack of this feature is at least troublesome, but implementation would be something more than allowing secret to be null as IMHO lots of security concerns must be addressed.

[inverse]

Any progress on this issue?

[Silverspur]

Also really interested by this issue, and more precisely by the possibility of customization of Implicit Grants.

[HenningCash]

+1 for this

Support for grant_type=password does not seem too hard to implement but is only a check if current client is allowed for the grant type (which is already done) and bypass the check for the client_secret then. The "security concerns" with public clients are more in the nature of OAuth than this bundle, aren't they?

[ghost]

+1 for solving this issue.

Not having public clients makes this bundle unusable for any front-end web app usage (Angular, Backbone, Ember..)

[inverse]

@ivan-spoiledmilk A solution for your situation as @alanbem suggested would be to setup an OAuth proxy API. Alex Bilbie has a nice article explaining this process.

http://alexbilbie.com/2014/11/oauth-and-javascript/

[HenningCash]

Alex Bilbie has a nice article explaining this process.

The article stinks, especially the cookie suggestion and using CSRF tokens again which are a pain in the ass when working with single page apps. Half of the article is about storing the client_secret we don't need with public clients.
I see the point in security concerns regarding untrusted clients, but can't we think about a solution with all the CORS stuff browsers of 21st century do support?

[maks-rafalko]

@alanbem @Cash2m with API proxy,

1. is it correct that each request will produce another http request?
2. is it correct that we should get response from real API and send all headers, data from proxy component back to user?
3. do you guys have an experience with such proxy? seems too complicated.

What is the progress of this issue @alanbem ?

[alanbem]

I see the point in security concerns regarding untrusted clients, but can't we think about a solution with all the CORS stuff browsers of 21st century do support?

Yeah, but APIs are not consumed only by browsers.

1. is it correct that each request will produce another http request?

Yes, why not. You can always leverage some caching techniques if performance is a concern.

1. is it correct that we should get response from real API and send all headers, data from proxy component back to user?

No necessities here, only tip is to do it as much handy as its possible for your proxy/end-user scripts.

1. do you guys have an experience with such proxy? seems too complicated.

If you ask me, my stateful (session enabled, no cookies with encrypted credentials) proxy would call underlying API with different authorization strategy - no OAuth preferably. Just simple user_id parameter or X-USER-ID header with users' id pulled out of session.
Only requirement would be that API utilising such authorization pattern should be hidden behind your public network.

Another idea would be creating extension grant which needs only user_id or an email (again this could be pulled out of session by your proxy) to provide proper long-lived token. Everything behind the scenes of course - this token, as well as clint_id and secret, would never be visible by SPA.
Again this API should be hidden.

[alanbem]

What is the progress of this issue @alanbem ?

I am working on it.

• I came to conclusion that requiring secret by implicit grant is weird (basically its just simplified and fully exposed authorization grant) and also dengerous.
  There is plethora of unexperienced developers who would just expose their secret - to the UAs - to get this grant working.

  It is OAuth2's fault - and as they say: You can't fix stupid. Only thing we can do is IMHO strongly discourage users of using implicit grant (in documentation) by making them aware of security threats.

• In terms of client authentication I think that authentication based on client_id and redirect_uri would be sufficient.

@Spomky what do you think?

[Spomky]

The implicit grant type is designed for scripting language or native applications (which are public clients), However, the use of this grant type is not restricted to public clients (confidential clients -password clients- can use it).
As you wrote, this grant type is dangerous because access tokens are issued without authentication: the client identity can be verified via the redirection URI used to deliver the access token to the client (that is why clients must store at least one redirection URI).

You are right: the documentation must be updated, not to discourage the implementation of this grant type, but

• to inform developers about the risks using this grant type,
• to encourage the use of authcode grant type for confidential clients.
• if a confidential client uses this grant type, it should only use this one (in this case, the secret is useless and never exposed).

Regarding this issue, the implementation of public clients is not easy; the library oauth2-php is not designed to support multiple client types/sources.

[Silverspur]

I'm working on a proxy as suggested above to solve the issue, but I'm having a little trouble forwarding to the TokenController: if by any chance, you could have a look at this related StackOverflow question, it would be really nice! Thanks!

[nclavaud]

Regarding this issue, the implementation of public clients is not easy ;

According to RFC6749 (section 2.3.1), the client_secret, when omitted, should be considered an empty string:

client_secret
         REQUIRED.  The client secret.  The client MAY omit the
         parameter if the client secret is an empty string.

I guess it could be fixed in library oauth2-php where getClientCredentials should fall back to an empty string instead of null.

This would allow omitting the client_secret (without having to set the secret property nullable as suggested in #282), which looks like the proper way to support public clients. Or am I missing something?

the library oauth2-php is not designed to support multiple client types/sources.

As for supporting multiple client types/sources, there is a paragraph in RFC6749 (section 2.1) which states:

   A client may be implemented as a distributed set of components, each
   with a different client type and security context (e.g., a
   distributed client with both a confidential server-based component
   and a public browser-based component).  If the authorization server
   does not provide support for such clients or does not provide
   guidance with regard to their registration, the client SHOULD
   register each component as a separate client.

so I feel like the way oauth2-php is designed would only require to create separate clients for public and confidential types. What do you think?