我覺得這裏真正的問題歸結爲範圍結合的概念。規範說明範圍參數是可選的,但範圍是否必須在實現OAuth 2的服務中定義的說明是正確的,這實際上取決於實現者(在本例中爲Spring)。
現在的範圍綁定的概念。在實現範圍或希望能夠從用戶訪問的信息時,您有兩種基本類型 - 綁定和未綁定範圍。使用綁定範圍時,需要在創建應用程序並獲取OAuth密鑰和祕密時定義範圍。如果實現未綁定的作用域(如Spring),則需要在第一次重定向調用期間定義作用域以使用戶身份驗證。在很多情況下,當沒有定義範圍時,實現未綁定範圍的服務將使用您可以訪問的默認用戶詳細信息。看來在Spring的情況下,範圍是必需的。
聲明:我之前沒有使用Spring安全OAuth實現。
只給你的綁定和非綁定的區別一些視覺效果,下面是一些例子:
Facebook的使用未綁定的範圍來請求用戶數據,所以他們最初的重定向請求可以是這樣的:
//construct Facebook auth URI
$auth_url = sprintf("%s?redirect_uri=%s&client_id=%s&scope=email,publish_stream",
$authorization_endpoint,
$callback_url,
$key);
在Gowalla的(回來時,Gowalla的是仍然可用)的情況下,他們使用的是綁定到OAuth的關鍵領域,所以當你做出初始請求的範圍並不需要被定義,讓您的請求看起來更像這樣(注意缺少範圍參數):
//construct Gowalla auth URI
$auth_url = sprintf("%s?redirect_uri=%s&client_id=%s",
$authorization_endpoint,
$callback_url,
$key);
我希望幫助,
喬恩
喬恩您好,感謝您的回答。實際上,Spring在本質上使用了一個綁定範圍,即我的客戶端應用程序在註冊時被賦予一個範圍,並且如果它們所請求的範圍與允許的範圍不同(它們可以請求它們允許的任何子集),則會出現一個錯誤被拋出。我不明白的是爲什麼不允許沒有要求的範圍,然後默認同意,在註冊後,範圍被退回。 – Ittai 2012-04-24 15:20:35
這實際上與PayPal Access使用的過程相同 - 您可以在應用程序中定義所需內容,然後在發出請求時再次定義。實際上沒有這樣做的理由,它可能只是用於額外的驗證。我想告訴你,規範中有這樣做的原因,但實際上並沒有 - 他們是如何選擇這樣做的。如果有幫助,我同意你100%的默認值。這是Facebook使用的模型,我非常喜歡它。 – 2012-04-26 17:41:28