Hi Nadeeshan, Can you please share the design and implementation details of the refresh token handling in connectors.
On Wed, Mar 18, 2015 at 10:11 PM, Buddhima Wijeweera <[email protected]> wrote: > Hi All, > > According to current status, we need to do this with connectors. > > So, through this mail, I would like to propose a probable solution on this. > > There'll be two new entries for 'init' section of a connector. So, in > generic case a init of a connector should looks like follows: > > <connector_name.init> > <consumerKey>{wso2:vault-lookup('xx.consumerKey')}</consumerKey> > <consumerSecret>xx</consumerSecret> > > <accessToken>{wso2:vault-lookup('xxx.oauth.accessToken')}</accessToken> > > *<refreshToken>{wso2:vault-lookup('xxx.oauth.refreshToken')}</refreshToken>* > * <tokenTimeout>10</tokenTimeout>* > </connector_name.init> > > Those 2 new parameters could be optional depending on the connector. In > brief, > * refreshToken - The refresh token obtain from a service > * tokenTimeout - Time-to-live of an access token. This could have a > default value (eg: 3600 seconds) > > So the flow should be as follows: > 1. A message comes to init phase > 2. check (the last access-token update time + token-timeout) against > current time > 3. if (the last access-token update time + token-timeout) > current time, > message can go ahead since token has not expired. > 4. if (the last access-token update time + token-timeout) < current time, > then access-token needs to update (may be refresh-token too, depending on > the service). Update the access-token. Keep track of the updated time & > update in-memory synapse configuration accordingly. > > One doubtful thing I found while developing the story is, where to store > the last token-updated-time (it also needs restricted to a tenant). My > suggestion for that is a local-entry unique to a connector. > The reason behind introducing tokenTimeout is, different services expire > access-token in different time-periods, so this will enable users to adjust > expiration-timeout accordingly. > > Rather than implementing this functionality connector-wise, I prefer this > to have at an abstract level. Also please note that, according to OAuth 2 > Authorization Framework Spec. (RFC 6749), the request to get a new > access-token should follow a standard methodology. > > So, I would like to hear your thoughts on this. > > Thank you! > > On Fri, Mar 6, 2015 at 5:51 PM, Vanjikumaran Sivajothy <[email protected]> > wrote: > >> Hi Buddhima, >> >> As a interim solution i am proposing to have a update the connector with >> the separate functionality. >> >> However, currently there is another discussion on the architecture >> mailing list to add this functionality in existing Oauth mediator. I >> believe, we can reuse the given component for connector development too and >> currently we are evaluating that. >> >> [1][Architecture] Improve ESB OAuth Mediator to automatically renew token >> >> On Fri, Mar 6, 2015 at 5:43 PM, Buddhima Wijeweera <[email protected]> >> wrote: >> >>> Hi Vanji, >>> >>> Thank you for the answer. >>> >>> So the point not clear is, are you proposing to add this functionality >>> for each connector? >>> I think this should be done at a higher level and make it less affect to >>> connector implementation. If so, we'll be able to reduce the cost of >>> changing each and every connector. >>> >>> Also, I think this is a mandatory requirement for all connectors and >>> start with most frequently using connectors eg: Twitter, Gmail etc., since >>> this is to make connectors ready for long-running production ESB instances. >>> >>> Thank you! >>> >>> >>> On Fri, Mar 6, 2015 at 5:20 PM, Vanjikumaran Sivajothy <[email protected]> >>> wrote: >>> >>>> Hi Buddhima, >>>> >>>> Please see my answers in line >>>> >>>> Best Regards, >>>> Vanji >>>> >>>> >>>> >>>> On Tue, Mar 3, 2015 at 8:34 PM, Buddhima Wijeweera <[email protected]> >>>> wrote: >>>> >>>>> Hi All, >>>>> >>>>> This is regarding OAuth token expiration and using Refresh Token for >>>>> updating the Access Token. >>>>> >>>>> *Problem:* >>>>> This problem currently emerged from ESB Connectors. After configuring >>>>> a connector according to documentation, it works fine for certain time and >>>>> become not usable. >>>>> >>>>> *Reason:* >>>>> Within the init of a connector we provide an Access Token. That Access >>>>> Token will have an expiration time. So after expiration time, the >>>>> connector >>>>> will not be usable. >>>>> >>>>> *Explanation:* >>>>> After a successful OAuth flow we receive an Access Token & a Refresh >>>>> Token from the service. But within the current implementation of >>>>> connectors >>>>> the Refresh Token is not being used. According to OAuth 2 Authorization >>>>> Framework Spec. (RFC 6749), at section "Refreshing an Access Token" >>>>> following type of request can be used to obtain a new Access Token. >>>>> >>>>> POST /token HTTP/1.1 >>>>> Host: server.example.com >>>>> Authorization: Basic czZCaGRSa3FppppnWDFmQmF0M2JW >>>>> Content-Type: application/x-www-form-urlencoded >>>>> >>>>> grant_type=refresh_token&refresh_token=tGzv3JOkF0XG5Qx2TlKWIA >>>>> >>>>> >>>>> >>>>> Also, it is noted that server MAY issue a new Refresh token in the >>>>> response and client should renew the Refresh Token too. >>>>> >>>>> Since refreshing Access Token implementation is not in connector >>>>> implementation, connectors will not be usable for long running production >>>>> environment. >>>>> >>>> >>>> Your concern is 100% correct and we have already taken this into >>>> consider after our first released of the connectors. The most of the >>>> connectors that are implemented in recent past contain the Oauth flow. If >>>> you can point out the connectors that need to be improve. That would be >>>> helpful us to prioritize development process. >>>> >>>> >>>>> >>>>> So, your thoughts on this would be highly appreciated. >>>>> >>>>> Thank you! >>>>> >>>>> -- >>>>> Buddhima Wijeweera >>>>> Software Engineer; WSO2 Inc.; http://wso2.com , >>>>> >>>>> Mobile: +94 71 427 9966 >>>>> Email: [email protected] >>>>> Blog: https://buddhimawijeweera.wordpress.com >>>>> GitHub Profile: https://github.com/Buddhima >>>>> >>>>> _______________________________________________ >>>>> Architecture mailing list >>>>> [email protected] >>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>> >>>>> >>>> >>>> >>>> -- >>>> Sivajothy Vanjikumaran >>>> *Senior Software Engineer* >>>> *Integration Technologies Team* >>>> *WSO2 Inc. http://wso2.com <http://wso2.com/>* >>>> *Mobile:(+94)777219209* >>>> [image: Facebook] <https://www.facebook.com/vanjikumaran> [image: >>>> Twitter] <https://twitter.com/vanjikumaran> [image: LinkedIn] >>>> <http://www.linkedin.com/pub/vanjikumaran-sivajothy/25/b31/293> [image: >>>> Blogger] <http://vanjikumaran.blogspot.com/> [image: SlideShare] >>>> <http://www.slideshare.net/vanjikumaran> >>>> >>>> This communication may contain privileged or other >>>> confidential information and is intended exclusively for the addressee/s. >>>> If you are not the intended recipient/s, or believe that you may >>>> have received this communication in error, please reply to the >>>> sender indicating that fact and delete the copy you received and in >>>> addition, you should not print, copy, re-transmit, disseminate, or >>>> otherwise use the information contained in this communication. >>>> Internet communications cannot be guaranteed to be timely, secure, error >>>> or virus-free. The sender does not accept liability for any errors >>>> or omissions >>>> >>> >>> >>> >>> -- >>> Buddhima Wijeweera >>> Software Engineer; WSO2 Inc.; http://wso2.com , >>> >>> Mobile: +94 71 427 9966 >>> Email: [email protected] >>> Blog: https://buddhimawijeweera.wordpress.com >>> GitHub Profile: https://github.com/Buddhima >>> >> >> >> >> -- >> Sivajothy Vanjikumaran >> *Senior Software Engineer* >> *Integration Technologies Team* >> *WSO2 Inc. http://wso2.com <http://wso2.com/>* >> *Mobile:(+94)777219209* >> [image: Facebook] <https://www.facebook.com/vanjikumaran> [image: >> Twitter] <https://twitter.com/vanjikumaran> [image: LinkedIn] >> <http://www.linkedin.com/pub/vanjikumaran-sivajothy/25/b31/293> [image: >> Blogger] <http://vanjikumaran.blogspot.com/> [image: SlideShare] >> <http://www.slideshare.net/vanjikumaran> >> >> This communication may contain privileged or other >> confidential information and is intended exclusively for the addressee/s. >> If you are not the intended recipient/s, or believe that you may >> have received this communication in error, please reply to the >> sender indicating that fact and delete the copy you received and in >> addition, you should not print, copy, re-transmit, disseminate, or >> otherwise use the information contained in this communication. >> Internet communications cannot be guaranteed to be timely, secure, error >> or virus-free. The sender does not accept liability for any errors >> or omissions >> > > > > -- > Buddhima Wijeweera > Software Engineer; WSO2 Inc.; http://wso2.com , > > Mobile: +94 71 427 9966 > Email: [email protected] > Blog: https://buddhimawijeweera.wordpress.com > GitHub Profile: https://github.com/Buddhima > > _______________________________________________ > Architecture mailing list > [email protected] > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- Kasun Indrasiri Software Architect WSO2, Inc.; http://wso2.com lean.enterprise.middleware cell: +94 77 556 5206 Blog : http://kasunpanorama.blogspot.com/
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
