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