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
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
