第四章：認(rèn)證（1）
隨著對API的理解，我們已經(jīng)學(xué)到了一些東西。我們知道什么是客戶端和服務(wù)器立叛，知道它們使用HTTP進行交談夭禽，知道它們使用特定的數(shù)據(jù)格式交談以理解彼此的話。雖然我們知道它們?nèi)绾谓徽勗椅桑沁€有一個非常重要的問題：服務(wù)器如何知道客戶端就是它所宣稱的那個呢传于？本章，我們?yōu)g覽客戶端向服務(wù)器證明自己身份的兩種方式醉顽。
虛擬世界的身份
以前你可能已經(jīng)在網(wǎng)站上注冊過帳號沼溜。在這個過程中，網(wǎng)站會詢問你一些私人信息游添，尤其是用戶名和密碼系草。這兩部分信息成為你的身份標(biāo)志。我們稱之為憑證唆涝。當(dāng)你再次訪問這個網(wǎng)站的時候找都，你可以通過提供這些憑證來登錄。
使用用戶名和密碼來登錄是身份認(rèn)證這一技術(shù)過程的例子廊酣。當(dāng)你和服務(wù)器進行認(rèn)證的時候能耻，你通過向服務(wù)器提供只有你自己知道（起碼我們希望只有你知道）的信息來證明自己的身份。一旦服務(wù)器知道你是誰亡驰，它會信任你晓猛，并且向你暴露賬戶的隱私數(shù)據(jù)。
API使用多種方式對客戶端進行認(rèn)證凡辱。這些方式稱為認(rèn)證方案“暗郏現(xiàn)在我們來看兩種方案。
基礎(chǔ)認(rèn)證
上面的登錄的例子就是最基礎(chǔ)的認(rèn)證方式煞茫。實際上帕涌，它的正式名稱就是基礎(chǔ)認(rèn)證。雖然這個名字毫無新意续徽，但是這個方案在API對客戶端進行認(rèn)證的時候是完全可以接受的蚓曼。
基礎(chǔ)認(rèn)證只要求提供用戶名和密碼∏张ぃ客戶端使用這兩個憑證纫版，組合成一個值，放置在HTTP的Authorization首部中和請求一起發(fā)送到服務(wù)器客情。
服務(wù)器收到請求后其弊，查看Authorization首部癞己，和自己存儲的憑證進行比較。如果用戶名和密碼可以和服務(wù)器上的用戶列表中的某一個匹配梭伐，服務(wù)器把它當(dāng)成那個用戶痹雅，完成請求。如果沒有匹配的用戶糊识，服務(wù)器返回一個特定的狀態(tài)碼（401）绩社，告訴客戶端認(rèn)證失敗，請求被拒絕赂苗。
雖然基礎(chǔ)認(rèn)證是一個有效的認(rèn)證方案愉耙，但是它使用相同的用戶名、密碼來使用API和管理賬戶拌滋，這不是理想的方案朴沿。這相當(dāng)于一個旅館給了客人一把整棟建筑的鑰匙而不是某個房間的鑰匙。
和API類似败砂，有些時候客戶端的許可應(yīng)該和賬戶所有者不同悯仙。比如，一個企業(yè)主雇傭了一個承包商吠卷，讓他寫一個使用收益API的程序锡垄。如果所有者輕易相信承包商的憑證就會有風(fēng)險，因為不道德的承包商可能會修改密碼祭隔，使得企業(yè)主不能使用自己的賬戶货岭。很顯然，如果能有一個替代方案就好了疾渴。
API密鑰認(rèn)證
API密鑰認(rèn)證技術(shù)可以克服共享憑證的缺陷千贯，它要求使用唯一的密鑰來訪問API。本方案中搞坝，密鑰通常是一長串的字母和數(shù)字搔谴，和賬戶所有者的登錄密碼是不同的。所有者將密鑰給予客戶端桩撮，類似于旅館將一個房間的鑰匙給予客人敦第。
當(dāng)客戶端使用API密鑰認(rèn)證時，服務(wù)器知道應(yīng)該允許客戶端訪問數(shù)據(jù)店量，但是現(xiàn)在可以有選擇的限制管理功能芜果，比如修改密碼或者刪除賬戶。有時候融师，密鑰使用起來如此簡單右钾，用戶都不需要給出密碼。API密鑰認(rèn)證的靈活性就是，既可以限制控制權(quán)限舀射，又可以保護用戶的密碼窘茁。
那么，API密鑰在哪兒呢脆烟？也有一個專門的首部山林，是嗎？很不幸浩淘，沒有。和基礎(chǔ)認(rèn)證不同吴攒，API密鑰認(rèn)證不是一個由嚴(yán)格的規(guī)則構(gòu)建的標(biāo)準(zhǔn)张抄，它來自于web早期幾個公司的構(gòu)想。結(jié)果就是洼怔，API認(rèn)證有點類似蠻荒的西部署惯，不同的人有不同的實現(xiàn)方式。
隨著時間的流逝镣隶，出現(xiàn)了一些常見的方案极谊。其中之一是讓客戶端將密鑰放在Authorization首部中，取代用戶名和密碼的位置安岂。另一個是將密鑰加到URL中（http://example.com?api_key=my_secret_key ）轻猖。不太常見的方法是將密鑰放到請求主體中緊挨著數(shù)據(jù)。不管放在哪里域那，效果是一樣的——它允許服務(wù)器對客戶端進行認(rèn)證咙边。
譯自
