Hi All,
According to the requirement of refreshing the access token we decided that
there should be a way to keep our refresh token persistently. Also using
the time out can be bit problematic since the access tokens can be revoked
also. Due to this reason we decided to depend on the API call to check
whether it is a valid access token and to get a new access token. So I will
explain the underlying architecture of the implementation here.
First of all at the configuration level we should pass *Access Token,
Consumer Key, Consumer Secret and Refresh Token. *We can do this at the
connector in it as follows.
<connector_name.init>
<consumerKey>XX</consumerKey>
<consumerSecret>XX</consumerSecret>
<accessToken>XX</accessToken>
*<refreshToken>XX</refreshToken>*
</connector_name.init>
After this configuration, validating and retrieving the access token is
done at the connector level. In order to support the persistent property
requirement we had to implement a way to keep a persistent property value,
which can be found at [1] and [2]. For more information refer [3].
At the connector level we use this persistent property implementation to
store the access token. Please refer [4] for the connector level
implementation for the googleSpreadsheet Connector and the gmailRest
Connector
[1] https://github.com/wso2/carbon-mediation/pull/198
[2] https://github.com/wso2/wso2-synapse/pull/214
[3]
http://wso2-oxygen-tank.10903.n7.nabble.com/Persisting-content-into-registry-from-the-mediation-layer-td118549.html#a118551
[4]
https://github.com/wso2/esb-connectors/compare/master...nadeeshaan:RefreshToken_Init_Branch
Regards
On Mon, Jun 15, 2015 at 10:17 AM, Kasun Indrasiri <[email protected]> wrote:
> 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
