這是我們今天遇到的問題。在決定在這裏提出問題之前，我儘可能地在網上查看。OAuth 2.0訪問令牌響應中是否應包含resource_owner/User-id？
問題是，當用戶使用用戶名/密碼發出「訪問令牌請求」時，訪問令牌響應是否應該包含「用戶ID」字段？
OAuth 2.0 spec表示可以有一個額外的字段（在spec中搜索「example_parameter」）作爲訪問令牌響應的一部分。這個額外的字段可以是用戶ID嗎？
但是，許多像facebook/google/twitter這樣的公司並未提供用戶標識作爲訪問令牌響應的一部分。用戶ID是作爲驗證令牌響應的一部分提供的。
未提供用戶標識作爲訪問令牌響應的一部分的原因是什麼？如果我們需要一個用戶ID，爲什麼我們必須再打一次電話（額外的往返旅程）？提供用戶ID作爲訪問令牌響應的一部分的後果是什麼？
大多數應用程序不想泄漏他們的用戶id到UI層。這通常被認爲是不好的做法。如果您將用戶標識發送到用戶界面層，用戶界面將能夠請求有關該用戶標識的信息並獲取有關它的信息...
這提出了一個安全問題，因爲客戶端通常可以修改這些調用獲取有關其他用戶ID的信息......如果您每次都要驗證每個呼叫以驗證令牌是否綁定到該用戶ID，那麼讓客戶端自己通過用戶ID可能是浪費，您已經在做查找，因此您不妨將數據保留在服務內部。
這也設置你很好地改變你的用戶標識的概念，在未來，也許改變它是組ID，或電子郵件地址，而不是數據庫的用戶ID ...
OAuth2.0的是授權框架並且不處理用戶認證。
的問題是，當用戶進行「訪問令牌請求」有 用戶名/密碼，應該訪問令牌響應包含「用戶ID」 場？在此背景下，資源
這的確是一個客戶端請求的訪問令牌，並在許多情況下，客戶不想知道它只是想要一個令牌資源所有者的ID號，以便它調用它的端點在資源服務器上。資源服務器可以從訪問令牌的內容中識別用戶。
OpenID Connect可用於擴展OAuth2.0以包含ID令牌。這以標準格式提供基本用戶信息，而不需要調用另一個端點。
訪問令牌通常是一個不記名令牌，允許您調用API。在OpenID Connect中，您使用訪問令牌來調用稱爲user_info端點的api，該端點返回包含有關該人的信息的JSON對象，例如名字，姓氏等。如果您正在尋找免費的開源中央身份驗證服務器，支持OAuth2，你應該看看Gluu服務器http://gluu.org