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* *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
