Re: [Architecture] [AppM] [CDM] Mobile Application List Service

[Dilshan Edirisuriya]

Hi Dilan,

Where do you store images and application binaries? When it comes to
application binaries it seems anyone can download it when they have the
above url. How do we prevent that?

Regards,

Dilshan

On Thu, Mar 5, 2015 at 7:52 AM, Chathura Dilan  wrote:

> Hi All,
>
> To provide app information to CDM, we decided to developed a Jax-RS web
> service. This web service will be connected to CDM through mutual auth.
>
> The information about web service as follows
>
> *Path*
>
> GET mobileapp-services/v1/apps
>
> *Parameters*
>
>
>
> *Name*
>
> *Located in*
>
> *Description*
>
> *Required*
>
> *Type*
>
> q
>
> query
>
> Search the app by name
>
> false
>
> string
>
> limit
>
> query
>
> Number of records to be displayed
>
> false
>
> number
>
> offset
>
> query
>
> Offset of the app list
>
> false
>
> number
>
>
>
>  *Responses*
>
> *Status 200*
>
> Sample Response
>
> {
>   "apps": [
> {
>   "id": "Szqw45623",
>   "name": "WSO2 Con",
>   "type": "entrpirse",
>   "platform": "android",
>   "version": 1,
>   "location": "https://192.168.1.1:9443/apps/app.apk";,
>   "iconImage": "https://192.168.1.1:9443/images/app.png";,
>   "packageName": "com.wso2.conapp",
>   "identifier": "com.wso2.conapp"
> },
> {
>   "id": "R456xxEr",
>   "name": "Antivirus",
>   "type": "public",
>   "platform": "android",
>   "version": 1,
>   "iconImage": "https://192.168.1.1:9443/images/app1.png";,
>   "packageName": "com.wso2.antiv",
>   "identifier": "com.wso2.antiv"
> },
> {
>   "id": "DD4567we",
>   "name": "WSO2 Dinner on Demand",
>   "type": "public",
>   "platform": "ios",
>   "version": 2,
>   "iconImage": "https://192.168.1.1:9443/images/app.png";,
>   "appIdentifier": "com.wso2.dod",
>   "identifier": "com.wso2.dod"
> },
> {
>   "id": "Tyere34343",
>   "name": "WSO2 Sports",
>   "type": "webapp",
>   "platform": "all",
>   "version": 2,
>   "location": "https://192.168.1.1:9443/apps/webapp";,
>   "iconImage": "https://192.168.1.1:9443/images/app.png";,
>   "identifier": "https://192.168.1.1:9443/apps/webapp";
> }
>   ],
>   "query": {
> "status": "ok",
> "found": 4,
> "length": 10,
> "offset": 110,
> "total": 114
>   }
> }
>
>
> Also Please mention if you need any search queries for this version of the
> API
>
> --
> Regards,
>
> Chatura Dilan Perera
> *(Senior Software Engineer** - WSO2 Inc.**)*
> www.dilan.me
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


-- 
Dilshan Edirisuriya
Senior Software Engineer - WSO2
Mob: + 94 777878905
http://wso2.com/
https://www.linkedin.com/profile/view?id=50486426
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

[Architecture] [APIM] Decoupling Authorization Server - Mapping existing oAuth applications with API manager.

[Roshan Wijesena]

Hi,

When providing the capability to plug in an External Authorization Server
for managing tokens and clients, a need may also arise to associate already
existing Oauth clients with Applications created in API Manager.

We are working on a solution to cater the above requirement. When users log
in to the store and navigate to the subscription page, they can decide
whether they want to an entirely new OAuth client or associate an existing
OAuth client with the Application in APIM side. Users can associate an
existing Oauth App by enabling a check box. If they check the option, they
will be given a text box to enter the consumer key of the oAuth client.
Once users click on generate button we will create a new mapping for that
consumer key with the API Manager application.

If someone wants to disable this feature completely  they can turn it off
by changing  a config setting  from api-manger.xml config file.

Regards
Roshan.

-- 
Roshan Wijesena.
Senior Software Engineer-WSO2 Inc.
Mobile: *+94719154640*
Email: ros...@wso2.com
*WSO2, Inc. :** wso2.com *
lean.enterprise.middleware.
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Improve ESB OAuth Mediator to automatically renew token

[Amila De Silva]

Hi Madusanka,

I think it's better to provide an option to store an Access Token Obtained
from an Authorization Server.
>From what I understood, in this scenario, the API acts as a client and the
token generated or provided is only another form of credential used to
access the backend. If this is the case, is it correct to put this under
the OAuth Mediator? The OAuth Mediator seems to validating the Token before
sending it to the backend, but here what we need is a way of embedding a
token.

On Thu, Feb 12, 2015 at 11:25 AM, Madusanka Premaratne 
wrote:

> Hi,
> We need to add a property to the messageContext to store the access token.
> Planning to use the property name as *oauth.accessToken*.
> The OAuth Mediator configuration changes are as below.
>
> Current OAuth configurations for the token verification,
> 
> remoteServiceUrl="https://10.100.5.179:9444/services/";
> username="user"
> password="user"/>
>
> ​The new configuration for both token generation and validation​. Newly
> added ones are bolded to identify easily.
> 
> *mode="tokenGenerate"*
>
> remoteServiceUrl="https://10.100.5.179:9444/services/";
> username="user"
> password="user">
>
> **
>
> 
>
> ​Thanks,​
>
>
> On Thu, Feb 12, 2015 at 10:23 AM, Nuwan Dias  wrote:
>
>> Hi Madusanka,
>>
>> Shall we come up with the OAuth mediator configuration changes
>> (additions) we'll be coming up with to support this feature?
>>
>> Thanks,
>> NuwanD.
>>
>> On Wed, Feb 11, 2015 at 4:44 PM, Madusanka Premaratne <
>> madusan...@wso2.com> wrote:
>>
>>> Hi All,
>>> In API Manager, we only support secure endpoints through basic auth. To
>>> improve it to use OAuth, we are going to use ESB OAuth Mediator. But
>>> currently the above mediator only validates the keys and the consumer.
>>>
>>> Improvement :
>>>
>>>- Feed client key, secret and *token endpoint* to the mediator from
>>>the UI.
>>>- Generate a token for the consumer and stores it to use with API
>>>Manager (or any other product)
>>>- Store the lifetime / remaining time of the token
>>>- If token expires, generate a token automatically and store it for
>>>future use
>>>
>>> Please see the attachment below for graphical representation[1]
>>>
>>> [1] -
>>> https://drive.google.com/a/wso2.com/file/d/0B6h6rqrZ11fFQWZ5UkJXZ1JZX2c/view?usp=sharing
>>>
>>> Your feedback and suggestions are welcome.
>>> ​Thanks,​
>>>
>>> --
>>> *Madusanka Premaratne* | Associate Software Engineer
>>> WSO2, Inc | lean. enterprise. middleware.
>>> #20, Palm Grove, Colombo 03, Sri Lanka
>>> Mobile: +94 71 835 70 73| Work: +94 112 145 345
>>> Email: madusan...@wso2.com | Web: www.wso2.com
>>>
>>> [image: Facebook]  [image:
>>> Twitter]  [image: Google Plus]
>>>  [image:
>>> Linkedin]  [image: Instagram]
>>>  [image: Skype]
>>> 
>>>
>>>
>>
>>
>> --
>> Nuwan Dias
>>
>> Associate Tech Lead - WSO2, Inc. http://wso2.com
>> email : nuw...@wso2.com
>> Phone : +94 777 775 729
>>
>
>
>
> --
> *Madusanka Premaratne* | Associate Software Engineer
> WSO2, Inc | lean. enterprise. middleware.
> #20, Palm Grove, Colombo 03, Sri Lanka
> Mobile: +94 71 835 70 73| Work: +94 112 145 345
> Email: madusan...@wso2.com | Web: www.wso2.com
>
> [image: Facebook]  [image:
> Twitter]  [image: Google Plus]
>  [image:
> Linkedin]  [image: Instagram]
>  [image: Skype]
> 
>
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


-- 
*Amila De Silva*

WSO2 Inc.
mobile :(+94) 775119302
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Improve ESB OAuth Mediator to automatically renew token

[Buddhima Wijeweera]

Hi Madusanka,

Sorry, it's a bit late when I spot this.

I have concerns on this implementation.

* Are you going to completely handle OAuth flow through the mediator
(without IS)?
* What is "tokenServer" refers to?

Your explanation is appreciated.

Thank you!


On Fri, Feb 13, 2015 at 8:39 AM, Madusanka Premaratne 
wrote:

> Hi Nuwan,
> Noted and I will do.
>
> Thanks,
>
> On Fri, Feb 13, 2015 at 8:37 AM, Madusanka Premaratne  > wrote:
>
>> Hi Lalaji,
>> No we are not going to store in those in the db. We are going to store it
>> in the cache and planning to use the request URL as the cache key.
>> I am sorry If I confuse you while having offline conversation.
>>
>> Thanks,
>>
>> On Thu, Feb 12, 2015 at 5:57 PM, Lalaji Sureshika 
>> wrote:
>>
>>> Hi Madusanka,
>>>
>>> On Wed, Feb 11, 2015 at 6:14 AM, Madusanka Premaratne <
>>> madusan...@wso2.com> wrote:
>>>
 Hi All,
 In API Manager, we only support secure endpoints through basic auth. To
 improve it to use OAuth, we are going to use ESB OAuth Mediator. But
 currently the above mediator only validates the keys and the consumer.

 Improvement :

- Feed client key, secret and *token endpoint* to the mediator from
the UI.

 In this case, the consumer key and secret needed for
>>> backend endpoint will be pre-defined for each creating API from publisher
>>> UI..One other thing which we may need to consider is when the end
>>> user[client app] is having the oauth2 token needed from back-end endpoint
>>> and that token will be sent directly with each request [by either skipping
>>> oauth2 layer in APIM],at this time,we will not need to dynamically generate
>>> the back-end endpoint needed oauth2 token again..
>>>

- Generate a token for the consumer and stores it to use with API
Manager (or any other product)
- Store the lifetime / remaining time of the token
- If token expires, generate a token automatically and store it for
future use

Are we going to store the back-end required oauth2 token
>>> information also in APIM level db storage..? Isn't it better to maintain a
>>> local cache with these information and if the information not in cache,do
>>> the token generation call against back-end token endpoint,instead keeping
>>> those information again in APIM db storage level..?
>>>
>>>
>>>
 Please see the attachment below for graphical representation[1]

 [1] -
 https://drive.google.com/a/wso2.com/file/d/0B6h6rqrZ11fFQWZ5UkJXZ1JZX2c/view?usp=sharing

 Your feedback and suggestions are welcome.
 ​Thanks,​

 --
 *Madusanka Premaratne* | Associate Software Engineer
 WSO2, Inc | lean. enterprise. middleware.
 #20, Palm Grove, Colombo 03, Sri Lanka
 Mobile: +94 71 835 70 73| Work: +94 112 145 345
 Email: madusan...@wso2.com | Web: www.wso2.com

 [image: Facebook]  [image:
 Twitter]  [image: Google Plus]
  [image:
 Linkedin]  [image: Instagram]
  [image: Skype]
 


 ___
 Architecture mailing list
 Architecture@wso2.org
 https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture


>>>
>>>
>>> --
>>> Lalaji Sureshika
>>> WSO2, Inc.;  http://wso2.com/
>>> email: lal...@wso2.com; cell: +94 71 608 6811
>>> blog: http://lalajisureshika.blogspot.com
>>>
>>>
>>>
>>> ___
>>> Architecture mailing list
>>> Architecture@wso2.org
>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>
>>>
>>
>>
>> --
>> *Madusanka Premaratne* | Associate Software Engineer
>> WSO2, Inc | lean. enterprise. middleware.
>> #20, Palm Grove, Colombo 03, Sri Lanka
>> Mobile: +94 71 835 70 73| Work: +94 112 145 345
>> Email: madusan...@wso2.com | Web: www.wso2.com
>>
>> [image: Facebook]  [image:
>> Twitter]  [image: Google Plus]
>>  [image:
>> Linkedin]  [image: Instagram]
>>  [image: Skype]
>> 
>>
>>
>
>
> --
> *Madusanka Premaratne* | Associate Software Engineer
> WSO2, Inc | lean. enterprise. middleware.
> #20, Palm Grove, Colombo 03, Sri Lanka
> Mobile: +94 71 835 70 73| Work: +94 112 145 345
> Email: madusan...@wso2.com | Web: www.wso2.com
>
> [image: Facebook]  [image:
> Twitter]  [image: Google Plus]
>  [image:
> Linkedin] 

[Architecture] [APIM] Decoupling Authorization Server - Configuring Application Token Generation

[Amila De Silva]

Hi,

Currently in API Store when a user clicks on Generate button after
subscribing to an API, following two operations happen in a single call,

a. Getting a Consumer key and a secret for the application.
b. Generating an Access Token.

However when integrating with external Authorization Servers, there can be
scenarios where the Authorization Server doesn’t allow generating
Application Tokens. As there won’t be  an access token to be shown in the
UI in such cases, an option should be given to configure creating the
Access Token.

Two options can be provided to control this behaviour;

1. Creating client details and Access Token using two separate calls

When the user clicks on Generate button, only the Consumer ID and Secret
will be generated. Then the user would have to click on another button to
get the Access Token. If the user doesn’t need the Access Token they can
simply remove the second button from the UI.

2. Provide a configuration to control Application Token Creation

When configuring the Key Manager, users can specify whether they want to
create an Application Token. When it’s enabled a token will be generated as
the Consumer Key/Secret is created, and when it’s disabled Tokens won’t be
created or displayed in the UI.

Planning to go with option 2, since it involves less changes. Please share
your thoughts on this approach.
-- 
*Amila De Silva*

WSO2 Inc.
mobile :(+94) 775119302
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Using Refresh token in ESB connectors

[Vanjikumaran Sivajothy]

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 
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 
> wrote:
>
>> Hi Buddhima,
>>
>> Please see my answers in line
>>
>> Best Regards,
>> Vanji
>>
>>
>>
>> On Tue, Mar 3, 2015 at 8:34 PM, Buddhima Wijeweera 
>> 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 czZCaGRSa3FnWDFmQmF0M2JW
>>> 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: buddh...@wso2.com
>>> Blog:   https://buddhimawijeweera.wordpress.com
>>> GitHub Profile: https://github.com/Buddhima
>>>
>>> ___
>>> Architecture mailing list
>>> Architecture@wso2.org
>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>
>>>
>>
>>
>> --
>> Sivajothy Vanjikumaran
>> *Senior Software Engineer*
>> *Integration Technologies Team*
>> *WSO2 Inc. http://wso2.com *
>> *Mobile:(+94)777219209*
>> [image: Facebook]  [image:
>> Twitter]  [image: LinkedIn]
>>  [image:
>> Blogger]  [image: SlideShare]
>> 
>>
>> 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: buddh...@wso2.com
> Blog:   https://buddhimawijeweera.wordpress.com
> GitHub Profile: https://github.com/Buddhima
>



-- 
Si

Re: [Architecture] Using Refresh token in ESB connectors

[Buddhima Wijeweera]

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 
wrote:

> Hi Buddhima,
>
> Please see my answers in line
>
> Best Regards,
> Vanji
>
>
>
> On Tue, Mar 3, 2015 at 8:34 PM, Buddhima Wijeweera 
> 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 czZCaGRSa3FnWDFmQmF0M2JW
>> 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: buddh...@wso2.com
>> Blog:   https://buddhimawijeweera.wordpress.com
>> GitHub Profile: https://github.com/Buddhima
>>
>> ___
>> Architecture mailing list
>> Architecture@wso2.org
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>>
>
>
> --
> Sivajothy Vanjikumaran
> *Senior Software Engineer*
> *Integration Technologies Team*
> *WSO2 Inc. http://wso2.com *
> *Mobile:(+94)777219209*
> [image: Facebook]  [image: Twitter]
>  [image: LinkedIn]
>  [image:
> Blogger]  [image: SlideShare]
> 
>
> 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: buddh...@wso2.com
Blog:   https://buddhimawijeweera.wordpress.com
GitHub Profile: https://github.com/Buddhima
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Using Refresh token in ESB connectors

[Vanjikumaran Sivajothy]

Hi Buddhima,

Please see my answers in line

Best Regards,
Vanji



On Tue, Mar 3, 2015 at 8:34 PM, Buddhima Wijeweera 
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 czZCaGRSa3FnWDFmQmF0M2JW
> 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: buddh...@wso2.com
> Blog:   https://buddhimawijeweera.wordpress.com
> GitHub Profile: https://github.com/Buddhima
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


-- 
Sivajothy Vanjikumaran
*Senior Software Engineer*
*Integration Technologies Team*
*WSO2 Inc. http://wso2.com *
*Mobile:(+94)777219209*
[image: Facebook]  [image: Twitter]
 [image: LinkedIn]
 [image:
Blogger]  [image: SlideShare]


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
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture