Hi Prabath/Johan, Do we allow to set an expiration time to this client secret ? Because as in the DCR spec [1], for the response it is required attribute ' client_secret_expires_at' and we set it as 0 because of it will never expired.
[1] https://openid.net/specs/openid-connect-registration-1_0.html#RegistrationResponse *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 5:46 PM, Prabath Siriwardana <[email protected]> wrote: > > > On Thu, Jun 2, 2016 at 10:30 PM, Indunil Upeksha Rathnayake < > [email protected]> wrote: > >> Hi, >> I am working on 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?* >> > > I guess (as discussed in this thread already) - having the ability to > change the consumer secret would be enough. Changing the consumer key is > bit challanging too - we would have all the analytics data against the > consumer key. > > Also - consumer key is not something - someone would remember and use - so > I don't think its same as the username - so I don't see any need to change > it. > > >> >> >> >> 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"?* >> > > Revoking an app means - mostly the revoking of its consumer secret (the > previous scenario). > > Another couple of use cases we can address with this: > > 1. Blocking an app temporary - Deactivate the App - and the Activate it > after sometime - nothing to do with the consumer secret revocation. > > 2. Ability to revoke an access token (s) issued on behalf of a user for a > particular app. > > 3. Ability to revoke all the access tokens issued on behalf of a user > across all the apps. > > Thanks & regards, > -Prabath > > >> >> >> Really value your ideas/suggestions on improving this feature. >> >> 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 >> >> > > > -- > Thanks & Regards, > Prabath > > Twitter : @prabath > LinkedIn : http://www.linkedin.com/in/prabathsiriwardena > > Mobile : +1 650 625 7950 > > http://facilelogin.com > > _______________________________________________ > 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
