Hi, It depends on what user prefer. Comparing with username password analogy, if the user need to change the consumer key for some reason, it may be nice if the user can change the consumer key. But the main point here is the consumer key is going to be generated. User can't give what he likes. In that case it is not exactly like the username password scenario.
At the same time, AFAIU, because of the same reason above there is no point of having the option to regenerate the consumer key for an existing app. This may complicate things. Hence, I also feel like it will be enough for the user to have the option to regenerate the client secret. On Fri, Jun 3, 2016 at 11:51 AM, Farasath Ahamed <[email protected]> wrote: > Hi, > > Since client_id is simply an identifier for the OAuth application, is it > really required to regenerate the client_id when the client_secret is > compromised? > > Isn't it be similar to a situation where we are changing our username and > password because our password was compromised? > > > > Farasath Ahamed > Software Engineer, > WSO2 Inc.; http://wso2.com > lean.enterprise.middleware > > > Email: [email protected] > Mobile: +94777603866 > Blog: blog.farazath.com > Twitter: @farazath619 <https://twitter.com/farazath619> > > On Fri, Jun 3, 2016 at 11:32 AM, Harsha Thirimanna <[email protected]> > wrote: > >> Hi Farasath, >> >> In that case, we have to create a new application if some one wants to >> reset the consumer key. That will not be a good experience to the user and >> specification also not specifically saying that only we should revoke >> consumer key or both. >> >> An authorization server may revoke a client's secret in order to >> prevent abuse of a revealed secret. >> >> >> Note: This measure will immediately invalidate any authorization >> "code" or refresh token issued to the respective client. This might >> unintentionally impact client identifiers and secrets used across >> multiple deployments of a particular native or web application. >> >> >> >> *Harsha Thirimanna* >> Associate Tech Lead; WSO2, Inc.; http://wso2.com >> * <http://www.apache.org/>* >> *email: **[email protected]* <[email protected]>* cell: +94 71 5186770 * >> *twitter: **http://twitter.com/ <http://twitter.com/afkham_azeez>* >> *harshathirimannlinked-in: **http: >> <http://lk.linkedin.com/in/afkhamazeez>**//www.linkedin.com/pub/harsha-thirimanna/10/ab8/122 >> <http://www.linkedin.com/pub/harsha-thirimanna/10/ab8/122>* >> >> *Lean . Enterprise . Middleware* >> >> >> On Fri, Jun 3, 2016 at 11:11 AM, Farasath Ahamed <[email protected]> >> wrote: >> >>> Hi Indunil, >>> >>> In a case of client_secret being revealed wouldn't it be sufficient only >>> to regenerate the client_key without regenerating the consumer key? In >>> Google API console I have noticed that you only have the option to reset >>> the client secret of an OAuth application. If you want to regenerate both >>> client_id and client_secret you simply delete the app and create a new one. >>> >>> >>> Thanks, >>> Farasath Ahamed >>> Software Engineer, >>> WSO2 Inc.; http://wso2.com >>> lean.enterprise.middleware >>> >>> >>> Email: [email protected] >>> Mobile: +94777603866 >>> Blog: blog.farazath.com >>> Twitter: @farazath619 <https://twitter.com/farazath619> >>> >>> On Fri, Jun 3, 2016 at 10:21 AM, Indunil Upeksha Rathnayake < >>> [email protected]> wrote: >>> >>>> Hi, >>>> I am working on [1] for implementing regeneration of client secret/key >>>> of an oauth app and revocation of an oauth app for the next milestone >>>> release of Identity Server. Appreciate your feedbacks on the following >>>> approaches I have taken. >>>> >>>> A trusted client would need to update the client secret/key, in order >>>> to prevent the abuse of revealed client secret/key. So for addressing that, >>>> I am working on adding two options as *Regenerate Client Secret* and >>>> *Regenerate >>>> Consumer Key* for oauth applications in IS. After a client secret/key >>>> get regenerated, that will immediately invalidate any active authorization >>>> code, access token or refresh token, issued to the respective client. >>>> >>>> >>>> >>>> *Will it be necessary to add two options for revoking client secret and >>>> key or better to go for a different approach?* >>>> And apart from that planning for the implementation of *Revoking an >>>> oauth app*. In there the oauth app will be revoked and that also will >>>> immediately invalidate any active authorization code, access token or >>>> refresh token, issued to the respective client. In order to activate the >>>> oauth app again, need to regenerate the client secret. >>>> >>>> >>>> *In there to activate the app, better to regenerate "both client key >>>> and secret" or "either client key or secret"?* >>>> >>>> Really value your ideas/suggestions on improving this feature. >>>> >>>> [1] https://redmine.wso2.com/issues/2135 >>>> >>>> Thanks and Regards >>>> -- >>>> Indunil Upeksha Rathnayake >>>> Software Engineer | WSO2 Inc >>>> Email [email protected] >>>> >>> >>> >>> _______________________________________________ >>> Architecture mailing list >>> [email protected] >>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>> >>> >> > > _______________________________________________ > Architecture mailing list > [email protected] > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- Hareendra Chamara Philips *Software Engineer* Mobile : +94 (0) 767 184161 <%2B94%20%280%29%20773%20451194> [email protected] <[email protected]>
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
