appid、appkey、appsecret、accesstoken

標籤：服務   檢索   預設   需要   不同   div   api   客戶   存在   

app_id, app_key, app_secret , 對於平台來說, 需要給你的 你的開發人員帳號分配對應的許可權:
1. app_id 是用來標記你的開發人員帳號的, 是你的使用者id, 這個id 在資料庫添加檢索, 方便快速尋找
2 app_key 和 app_secret 是一對出現的帳號, 同一個 app_id 可以對應多個 app_key+app_secret, 這樣 平台就可以分配你不一樣的許可權, 比如 app_key1 + app_secect1 只有唯讀許可權 但是 app_key2+app_secret2 有讀寫權限.. 這樣你就可以把對應的許可權 放給不同的開發人員. 其中許可權的配置都是直接跟app_key 做關聯的, app_key 也需要添加資料庫檢索, 方便快速尋找
3 至於為什麼 要有app_key + app_secret 這種成對出現的機制呢, 因為 要加密, 通常 在首次驗證(類似登入情境) , 你需要用 app_key(標記要申請的許可權有哪些) + app_secret(密碼, 表示你真的擁有這個許可權) 來申請一個token, 就是我們經常用到的 access_token, 之後的資料請求, 就直接提供access_token 就可以驗證許可權了.

上述3點說的有點多哈, 不知道講明白了沒, 順便再說一下簡化的情境:
1 省去 app_id, 他預設每一個使用者有且僅有一套許可權配置, 所以直接將 app_id = app_key , 然後外加一個app_secret就夠了. 
2 省去app_id 和 app_key, 相當於 app_id = app_key = app_secret, 通常用於開放性介面的地方, 特別是很多地圖類api 都採用這種模式, 這種模式下, 帶上app_id 的目的僅僅是統計 某一個使用者調用介面的次數而已了.   

AppID：應用的唯一標識AppKey：公匙（相當於帳號）AppSecret：私匙（相當於密碼）

token：令牌（到期失效）

使用方法

1. 向第三方伺服器請求授權時，帶上AppKey和AppSecret（需存在伺服器端）

2. 第三方伺服器驗證AppKey和AppSecret在DB中有無記錄

3. 如果有，產生一串唯一的字串（token令牌），返回給伺服器，伺服器再返回給用戶端

4. 用戶端下次請求敏感性資料時帶上令牌

appid、appkey、appsecret、accesstoken