On Fri, Mar 29, 2013 at 9:31 PM, Sumedha Rubasinghe <[email protected]>wrote:

> 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.
>
>
Yes that is true, but if the API has not been secured, do we really need to
show the consumer secret & key?
_______________________________________________
Dev mailing list
[email protected]
http://wso2.org/cgi-bin/mailman/listinfo/dev

Reply via email to