0

I am developing and API (laravel passport) services and a first-party app (VueJs) to consume api.

Api will have a 2 parts

  1. Public - means user do NOT need to be logged in to see a content

  2. Private - means user do NEED to be logged in to see a content

Token for Public areas:

Since the application is developed by trusted source (same developers for api) I should be using a Client Credentials grant-type. However, since this is also a web-app, client credentials' confidentiality is not guaranteed.

So then I would need to use an Implicit grant type where a client_secret is not required. Then a user will have to authorize, which doesn't make much sense for a first-party app.

Token for Private areas:

It is obvious that I just need to use a Resource Owner Password Credentials grant type. Confusion come, as the client credentials will still be passed together with user credentials. And the client credentials can be used in public areas.

I am so very confused as which of the grant type(s) should be used in this case? Or is it fine to just use different grant types together?

Duy Anh
  • 750
  • 1
  • 7
  • 24
  • so for your public API, if no authentication needed, it should be no security around it, right? – chenrui Jun 25 '17 at 15:44
  • as for private API, client_id/client_credentials set for "Resource Owner Password Credentials" and "Client Credentials" are different, since the grant_type in the HTTP header is different, one is with password, the other one is with client_credentials. So it would be handled in different security flows. – chenrui Jun 25 '17 at 15:46
  • @chenrui 1. Yes, even if it's api it still should be consumed using a token, whether it's implicit or authorization (cannot just open to public without some kind of security layer). 2. for private where user has to be logged in, "Resource Owner Password" is supposed to be. However, when sending a request a client secret will be send as well, which defeating the purpose of using implicit/authorization token in point one. – Duy Anh Jun 25 '17 at 18:57
  • 1. then your public API is not truly public. 2. I dont quite understand your second point. "Resource Owner Password" acts with user's creds, so it has user as context while "Client Credentials" it more machine to machine act. – chenrui Jun 25 '17 at 19:10
  • @chenrui 1. it is public in a sense that a user don't need to be registered to use (api will only be available for 1st party apps). 2. with just client_id and client_secret, anyone can have access to the api, and not only 1st party apps. (resource owner password still requires those 2 to be sent along with username & password) – Duy Anh Jun 26 '17 at 08:20
  • 1. in that sense, it still need to secure your API, otherwise, anyone can access. client credentials grant make works fine. 2. with private API, the client_id and client_secret need to be securely stored. It is just like your own password, if that got leaked, the way how to communicate to the server also got known by hacker, then it wont be secure anymore. – chenrui Jun 26 '17 at 11:57
  • @chenrui 1. I would still need to store a client secret on the web app (which is what I want to avoid) 2. That is exactly what is confusing me. How do I store it if it's a web app? – Duy Anh Jun 27 '17 at 02:28
  • check with this one https://stackoverflow.com/a/6217429/791609, I think there is no way to make client_id and client_secret secure on client side. The post did suggest the abuse detection approach, hope it helps. – chenrui Jun 27 '17 at 12:20

0 Answers0