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