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? > > 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 Blogs : https://medium.com/@lakwarus/ http://lakmalsview.blogspot.com/
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
