On Fri, Mar 29, 2013 at 7:36 PM, Afkham Azeez <[email protected]> wrote:

>
>
> On Fri, Mar 29, 2013 at 6:42 PM, Afkham Azeez <[email protected]> wrote:
>
>>
>>
>> On Fri, Mar 29, 2013 at 12:36 PM, Sumedha Rubasinghe <[email protected]>wrote:
>>
>>> 1.Your are a developer who have subscribed to 'twitter-search'  api
>>> 2. You write a mobile application that makes use of 'twitter-search' api
>>> 3. But if you hard code the Access Token in this mobile application, all
>>> your app installations will use the same access token
>>> 4. Thus from a management point of view,
>>> - it token expires - all app installations  will fail
>>> - if there is one malicious user, cannot revoke the token b'cos everyone
>>> will be impacted
>>>  - you cannot collect much useful statistics since every access happens
>>> through same token
>>> - and many more limitations
>>>
>>> 5. In order to solve issues like above, there is a token API through
>>> which each installation of the application can get their own token
>>> 6. During development time, you will be hardcoding Consumer Key &
>>> Consumer Secret (which are specific to the application) in side the code
>>> 7. When you application gets installed on my mobile, I login go the
>>> application using my username & password. If this is the first time after
>>> installation, you application calls Token API with following.
>>>
>>> "grant_type=password&username=sumedha&password=password" -H
>>> "Content-Type: application/x-www-form-urlencoded" -H "Authorization :Basic
>>> ****[ABC]" https://127.0.0.1:8243/login
>>>
>>> Here ****[ABC] = Base64Encode(consumer key + '.' + consumer secret)
>>>
>>> So inside the Token API,
>>> ****[ABC] identifies to which application token is generated,
>>> username/password combination authenticates Sumedha's login, it also
>>> records that token is issued under my name.
>>>
>>>
>> So these two values are valid only if the API has been secured, and is
>> irrelevant if it hasn't been secured?
>>
>>
> So from what I understood, the Consumer Key & Secret are valid only if the
> API is secured. You need to call an authorization API first, obtain a token
> and make the subsequent actual requests using that token. So, should we be
> generating these if the API was not secured? Also, is this information
> available in API-M docs?
>

OAuth2 token is the means of securing the API... API not secured  = no
token required.
There is a new doc coming up with 1.4.0 with this level of explanation.



-- 
/sumedha
m: +94 773017743
b :  bit.ly/sumedha
_______________________________________________
Dev mailing list
[email protected]
http://wso2.org/cgi-bin/mailman/listinfo/dev

Reply via email to