Hi Nuwan, My point is that the key we use must be a secret. If we use a separate key we can tell the developer to keep it a secret. But we can't ask them to keep the consumer key a secret (as per the OAuth spec).
There may not be any valid scenarios to share the consumer key with someone else by now, but if something comes up in future (through some other new spec) we are in trouble. IMO it's not worth taking that risk when we have a simple solution (i.e. generating a separate key when an application is created) to avoid that. On the other hand, I feel it's safe and clean to have these 2 security schemes separated. Thanks, Bhathiya On Mon, Jul 3, 2017 at 9:18 AM, Nuwan Dias <[email protected]> wrote: > I don't think there's a difference in using consumer-key vs a separate > key, in terms of security. Both are known to app developer and both require > it to be embedded in the App itself. Unless there's a special form/method > to protect the API Key when compared to protecting the consumer-key, I > think its fine to say api-key = consumer-key. > > On Mon, Jul 3, 2017 at 12:22 AM, Bhathiya Jayasekara <[email protected]> > wrote: > >> >> On Mon, Jul 3, 2017 at 12:00 AM, Lakmal Warusawithana <[email protected]> >> wrote: >> >>> >>> >>> On Sun, Jul 2, 2017 at 11:46 PM, Bhathiya Jayasekara <[email protected]> >>> wrote: >>> >>>> Hi Lakmal, >>>> >>>> On Sun, Jul 2, 2017 at 11:03 PM, Lakmal Warusawithana <[email protected]> >>>> wrote: >>>> >>>>> Hi Bhathiya, >>>>> >>>>> On Sun, Jul 2, 2017 at 6:52 PM, Bhathiya Jayasekara <[email protected] >>>>> > wrote: >>>>> >>>>>> Hi Lakmal, >>>>>> >>>>>> On Fri, Jun 30, 2017 at 4:21 PM, Lakmal Warusawithana < >>>>>> [email protected]> wrote: >>>>>> >>>>>>> >>>>>>> >>>>>>> On Fri, Jun 30, 2017 at 4:08 PM, Dimuthu Leelarathne < >>>>>>> [email protected]> wrote: >>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> We don't have to pick which APIs are accessed by API-key and which >>>>>>>> APIs are accessed by OAuth Key. That is not a typical usecase, IMO. >>>>>>>> >>>>>>>> - Publisher decides whether the API is allowed to be invoked by a >>>>>>>> API Key (less secure approach) >>>>>>>> >>>>>>> >>>>>>> +1 >>>>>>> >>>>>>> >>>>>>>> - A created application get OAuth key pair and a API Key >>>>>>>> >>>>>>> >>>>>>> We can use consumer key as API key IMO. >>>>>>> >>>>>> >>>>>> IMO we shouldn't use consumer key as the API key, because consumer >>>>>> key is not a secret (i.e. it is publicly avaiable). We could use consumer >>>>>> secret instead. But I don't think that's a good idea either, becuase >>>>>> exposing the consumer secret as API key reduces the secrecy of the >>>>>> consumer >>>>>> secret. Therefore I'm +1 to have a seperate key as API key for each >>>>>> application. >>>>>> >>>>>> >>>>> API key is use as less secure approach. If security is a concern, yes >>>>> we should use OAuth. Consumer key is only visible to an application. Yes >>>>> it >>>>> is exacted from the application code, but it is not visible to other >>>>> applications right? Or am I missing something? >>>>> >>>> >>>> The OAuth spec specifically mentions that *"Consumer Key is not a >>>> secret (and it should not be used alone for authentication)"*, which >>>> means we can't expect the consumer key is known only by the owner app. It >>>> can be publicly available anywhere. Therefore if we use it alone, it's more >>>> like no-security rather than less-security. Hence my suggestion to use a >>>> seperate key. >>>> >>> >>> There is nothing stop to use separate key. But, is any usecase of >>> publish consumer (publicly available) key by app owner? >>> >> >> I can't think of any. But as per the OAuth spec, there's no guarantee >> there won't be any. So IMO it's safe to go with a seperate key. >> >> Thanks, >> Bhathiya >> >> >>> >>> >>>> >>>> Thanks, >>>> Bhathiya >>>> >>>> >>>>> >>>>> The main objective of introducing API key is for provide less secure >>>>> method to access APIs and also use them in offline mode of the API GW. To >>>>> support these use cases, we already have the a key ( consumer key ) and we >>>>> have verification functionality in the GW. What we have to introduce is a >>>>> place in publisher to allow OAuth or API key or both. >>>>> >>>>> In the use of OAuth security, consumer key (API key) should be >>>>> pass implicitly and in the API key security, it should pass explicitly. We >>>>> can introduce an authentication header to identify API key. Other option >>>>> is >>>>> query parameter, but since it is open in the wire better not to allow. >>>>> >>>>> >>>>>> Thanks, >>>>>> Bhathiya >>>>>> >>>>>> >>>>>>> >>>>>>> >>>>>>>> - The application subscribes to APIs >>>>>>>> >>>>>>> >>>>>>> +1 >>>>>>> >>>>>>> >>>>>>>> - If the API is invoke-able using an API key, the application can >>>>>>>> use the API Key >>>>>>>> >>>>>>> >>>>>>> We can add custom authentication header for api-key and GW can >>>>>>> verify with the consumer key, if publisher allowed. >>>>>>> >>>>>>> Basically we have two do only two things; >>>>>>> >>>>>>> 1. Publisher decides whether the API is allowed to be invoked by >>>>>>> a API Key (less secure approach) >>>>>>> 2. We can add custom authentication header for api-key and GW >>>>>>> can verify with the consumer key, if publisher allowed. >>>>>>> >>>>>>> Other things are already in the system >>>>>>> >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> thanks, >>>>>>>> Dimuthu >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Fri, Jun 30, 2017 at 1:47 PM, Lakmal Warusawithana < >>>>>>>> [email protected]> wrote: >>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On Fri, Jun 30, 2017 at 1:45 PM, Lakmal Warusawithana < >>>>>>>>> [email protected]> wrote: >>>>>>>>> >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> Without going with application workflow, can we think about "get >>>>>>>>>> an key for an API" ? Basically we are giving an option to use API's >>>>>>>>>> even >>>>>>>>>> without creating an application. No consumer key, no consumer >>>>>>>>>> secret, just >>>>>>>>>> api key. >>>>>>>>>> >>>>>>>>>> thanks >>>>>>>>>> >>>>>>>>>> On Fri, Jun 30, 2017 at 10:33 AM, Isuru Haththotuwa < >>>>>>>>>> [email protected]> wrote: >>>>>>>>>> >>>>>>>>>>> I'm +1 for 2-a. We currently have a model where an keys are >>>>>>>>>>> generated for an Application and is shared among all the APIs which >>>>>>>>>>> are >>>>>>>>>>> subscribed to using that Application. Using an API key per >>>>>>>>>>> Application is >>>>>>>>>>> an extension of the current model and fits with the story. Using the >>>>>>>>>>> consumer key as the API Key might be confusing. >>>>>>>>>>> >>>>>>>>>>> On a different note, how does an Application developer decide >>>>>>>>>>> the criticality of an API? What if an application developer chooses >>>>>>>>>>> the API >>>>>>>>>>> Key option to invoke such a critical API that should be properly >>>>>>>>>>> secured >>>>>>>>>>> via regular OAuth tokens? IMHO there should be some control over >>>>>>>>>>> allowing >>>>>>>>>>> the Application developer to select whether to use API keys of >>>>>>>>>>> OAuth keys >>>>>>>>>>> for a particular API. >>>>>>>>>>> >>>>>>>>>>> On Fri, Jun 30, 2017 at 9:22 AM, Sachini De Silva < >>>>>>>>>>> [email protected]> wrote: >>>>>>>>>>> >>>>>>>>>>>> Hi all, >>>>>>>>>>>> >>>>>>>>>>>> Currently, API manager uses oauth2 to authenticate and >>>>>>>>>>>> authorize API requests. This assures security and is good for >>>>>>>>>>>> dealing with >>>>>>>>>>>> apis that handle sensitive data. However APIs with less critical >>>>>>>>>>>> functionalities and can be exposed through API key authentication. >>>>>>>>>>>> Unlike >>>>>>>>>>>> access tokens used in oauth2, API keys do not have an expiry time >>>>>>>>>>>> or a >>>>>>>>>>>> scope associated with them. So basically an API key grants >>>>>>>>>>>> unrestricted >>>>>>>>>>>> asses (in time or scope) to the API. >>>>>>>>>>>> >>>>>>>>>>>> Option 1 >>>>>>>>>>>> >>>>>>>>>>>> At application creation, the developer is given the chance to >>>>>>>>>>>> select which apis he is going to access through Oauth and API key >>>>>>>>>>>> types. >>>>>>>>>>>> Then he can proceed to API key generation where he gets a consumer >>>>>>>>>>>> key, >>>>>>>>>>>> consumer secret and an access token. In Oauth context, all these 3 >>>>>>>>>>>> keys are >>>>>>>>>>>> used. If the application has subscribed to any API through API key >>>>>>>>>>>> type, >>>>>>>>>>>> then the consumer key issued for the application can be used as >>>>>>>>>>>> the API key >>>>>>>>>>>> for those APIs. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Figure : >>>>>>>>>>>> Option 1 >>>>>>>>>>>> >>>>>>>>>>>> Option 2 >>>>>>>>>>>> >>>>>>>>>>>> At application creation, the developer is given the chance to >>>>>>>>>>>> select which apis he is going to access through Oauth and APIkey >>>>>>>>>>>> types. >>>>>>>>>>>> Then he can proceed to API key generation where he gets a consumer >>>>>>>>>>>> key, >>>>>>>>>>>> consumer secret and an access token. These will be used in calling >>>>>>>>>>>> APIs >>>>>>>>>>>> with Oauth.Then a one time option is given to generate API keys >>>>>>>>>>>> for other >>>>>>>>>>>> APIs the developer wishes to call through API key. This can either >>>>>>>>>>>> be a >>>>>>>>>>>> seperate API key each per APIs(Option 2-b) or one API key for all >>>>>>>>>>>> APIs. >>>>>>>>>>>> (Option 2-a) >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Figure : >>>>>>>>>>>> Option 2-a >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Figure >>>>>>>>>>>> : Option 2-b >>>>>>>>>>>> >>>>>>>>>>>> Appreciate your comments and suggestions. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Thank you, >>>>>>>>>>>> >>>>>>>>>>>> Sachini >>>>>>>>>>>> >>>>>>>>>>>> -- >>>>>>>>>>>> >>>>>>>>>>>> *Sachini De Silva* >>>>>>>>>>>> Software Engineer - WSO2 >>>>>>>>>>>> >>>>>>>>>>>> Email : [email protected] >>>>>>>>>>>> Mobile : +94778977970 <077%20897%207970> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> Thanks and Regards, >>>>>>>>>>> >>>>>>>>>>> Isuru H. >>>>>>>>>>> +94 716 358 048 <+94%2071%20635%208048>* <http://wso2.com/>* >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> Lakmal Warusawithana >>>>>>>>>> Director - Cloud Architecture; WSO2 Inc. >>>>>>>>>> Mobile : +94714289692 <+94%2071%20428%209692> >>>>>>>>>> Blogs : https://medium.com/@lakwarus/ >>>>>>>>>> http://lakmalsview.blogspot.com/ >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Lakmal Warusawithana >>>>>>>>> Director - Cloud Architecture; WSO2 Inc. >>>>>>>>> Mobile : +94714289692 <071%20428%209692> >>>>>>>>> Blogs : https://medium.com/@lakwarus/ >>>>>>>>> http://lakmalsview.blogspot.com/ >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Dimuthu Leelarathne >>>>>>>> Director, Solutions Architecture >>>>>>>> >>>>>>>> WSO2, Inc. (http://wso2.com) >>>>>>>> email: [email protected] >>>>>>>> Mobile: +94773661935 <+94%2077%20366%201935> >>>>>>>> Blog: http://muthulee.blogspot.com >>>>>>>> >>>>>>>> Lean . Enterprise . Middleware >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Lakmal Warusawithana >>>>>>> Director - Cloud Architecture; WSO2 Inc. >>>>>>> Mobile : +94714289692 <071%20428%209692> >>>>>>> Blogs : https://medium.com/@lakwarus/ >>>>>>> http://lakmalsview.blogspot.com/ >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> *Bhathiya Jayasekara* >>>>>> *Associate Technical Lead,* >>>>>> *WSO2 inc., http://wso2.com <http://wso2.com>* >>>>>> >>>>>> *Phone: +94715478185 <+94%2071%20547%208185>* >>>>>> *LinkedIn: http://www.linkedin.com/in/bhathiyaj >>>>>> <http://www.linkedin.com/in/bhathiyaj>* >>>>>> *Twitter: https://twitter.com/bhathiyax >>>>>> <https://twitter.com/bhathiyax>* >>>>>> *Blog: http://movingaheadblog.blogspot.com >>>>>> <http://movingaheadblog.blogspot.com/>* >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Lakmal Warusawithana >>>>> Director - Cloud Architecture; WSO2 Inc. >>>>> Mobile : +94714289692 <071%20428%209692> >>>>> Blogs : https://medium.com/@lakwarus/ >>>>> http://lakmalsview.blogspot.com/ >>>>> >>>>> >>>> >>>> >>>> -- >>>> *Bhathiya Jayasekara* >>>> *Associate Technical Lead,* >>>> *WSO2 inc., http://wso2.com <http://wso2.com>* >>>> >>>> *Phone: +94715478185 <+94%2071%20547%208185>* >>>> *LinkedIn: http://www.linkedin.com/in/bhathiyaj >>>> <http://www.linkedin.com/in/bhathiyaj>* >>>> *Twitter: https://twitter.com/bhathiyax <https://twitter.com/bhathiyax>* >>>> *Blog: http://movingaheadblog.blogspot.com >>>> <http://movingaheadblog.blogspot.com/>* >>>> >>> >>> >>> >>> -- >>> Lakmal Warusawithana >>> Director - Cloud Architecture; WSO2 Inc. >>> Mobile : +94714289692 <071%20428%209692> >>> Blogs : https://medium.com/@lakwarus/ >>> http://lakmalsview.blogspot.com/ >>> >>> >> >> >> -- >> *Bhathiya Jayasekara* >> *Associate Technical Lead,* >> *WSO2 inc., http://wso2.com <http://wso2.com>* >> >> *Phone: +94715478185 <+94%2071%20547%208185>* >> *LinkedIn: http://www.linkedin.com/in/bhathiyaj >> <http://www.linkedin.com/in/bhathiyaj>* >> *Twitter: https://twitter.com/bhathiyax <https://twitter.com/bhathiyax>* >> *Blog: http://movingaheadblog.blogspot.com >> <http://movingaheadblog.blogspot.com/>* >> > > > > -- > Nuwan Dias > > Software Architect - WSO2, Inc. http://wso2.com > email : [email protected] > Phone : +94 777 775 729 <077%20777%205729> > -- *Bhathiya Jayasekara* *Associate Technical Lead,* *WSO2 inc., http://wso2.com <http://wso2.com>* *Phone: +94715478185* *LinkedIn: http://www.linkedin.com/in/bhathiyaj <http://www.linkedin.com/in/bhathiyaj>* *Twitter: https://twitter.com/bhathiyax <https://twitter.com/bhathiyax>* *Blog: http://movingaheadblog.blogspot.com <http://movingaheadblog.blogspot.com/>*
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
