0
我正在使用OAuth來保護一些Web服務。 OAuth 2非常適合用戶使用API訪問他/她自己的數據的用例,或者授予他人訪問權限以代表他調用API的用例。手動生成OAuth訪問令牌
但是,最初的一組API用戶並不是非常技術性的,他們不希望爲了生成令牌而進行API調用。我正在考慮實施以下解決方案,但不確定這是否正確。
如果用戶是一個開發人員,那麼
- 有一個屏幕,在這裏,他/她可以註冊申請。這將生成一個API密鑰/祕密對。
- 要訪問他/她自己的數據(對於雙腿Auth),有一個UI屏幕,用戶可以在其中爲其註冊的應用程序生成一個訪問令牌。他可以在表格中指定範圍和持續時間。
- 如果他是第三方開發人員,那麼他需要將他的應用程序API密鑰傳遞給他需要訪問API並獲得訪問令牌的人員。
如果用戶想要另一個應用程序/開發者訪問代表他的API,然後
- 有一個屏幕,在那裏他可以進入第三方的API密鑰,範圍和授權的持續時間。他可以通過生成的訪問令牌誰就會訪問開發者的API的
我將使用相同的OAuth庫來產生,我會用,如果我走了Web服務的路線令牌。此外,我還可以在目前的情況沒有擴大或需求出現時開發服務,現有的代幣仍然可以工作。
當然,如果僅僅不提供令牌過期的選項,並且無論它在自然流程中如何,都可以解決這個問題。我試圖採用這種方法的全部原因是因爲客戶不想通過編寫代碼(或不能僅僅用於OAuth)。此外,我的API將在HTTPS上,因此獲取訪問令牌並不是微不足道的。不知道我理解你的觀點,即有人可以訪問客戶端ID和訪問令牌,因爲如果發生這種情況,我會被擰緊,而不管我採取什麼方法。 – anfab
只要你有代碼照顧Oauth,HTTPS就很好。但是一旦你編寫了本手冊,你就不能依賴開發人員來確保他只在正確的地方使用它。它可能通過電子郵件進行交換,聊天,發佈便箋以及不可以。在生成的訪問令牌上添加了無效期限,這隻會增加隨着時間的推移而發生的一些可能性。 – s1d