2015-07-21 81 views
0

應用程序設置可信應用程序與API之間的身份驗證

應用程序A:第三方,Windows桌面應用程序。這是用戶需要登錄的應用程序。登錄進行管理/本地認證

應用B:我們的應用程序,在Windows系統托盤中的應用。這個集成了應用程序A中提取信息,併發送至應用C.

應用C:這是我們的API,它的應用程序B調用中發送數據。

目前用戶需要創建使用GUI在應用程序C的帳戶,在應用程序B輸入用戶細節進行。但是用戶質疑這個過程,因爲他們沒有區分應用程序A和B之間的所有權,因爲它們緊密耦合。

鑑於我們可以相信,如果用戶在應用程序已登錄,他們是真正的,我要拿出一個解決方案,你不需要再創建一個登錄。這將基於應用程序B和C之間的信任以及檢測用戶是否登錄到應用程序A的能力。

最終結果將是,如果用戶登錄到應用程序A,則應用程序B檢測到並將用戶詳細信息發送給應用程序C.鑑於B之間存在信任關係,C用戶將不需要爲B和C之間的身份驗證做任何事情。但是C將使用登錄到A的用戶進行授權。

任何想法,我可以做到這一點?基於令牌或信任的應用程序認證的線條......

回答

0

這完全取決於該應用程序的公開接口。如果應用程序A具有可以查詢身份驗證狀態的API,則可以使用該API來實現您的身份驗證模式。

如果應用程序A支持先進的認證機制,如OAuth的,可以綁定到他們以及類似的結果。

如果它沒有,你是運氣不好。認證狀態交換沒有這樣的通用標準。

+0

應用程序A是一個獨立的應用程序,它不使用OAuth類型認證。我更懷疑在應用程序之間建立信任是否是個好主意。應用程序B可以檢測到應用程序A已通過驗證。雖然應用程序B不能攜帶驗證細節,但它可以信任應用程序A完成了必要的工作。因此B告訴C,A的用戶的細節,但是使用一致的靜態機制進行認證。想法是,用戶不必爲B/C創建另一個登錄 – user3614386

+0

Wether這是一個有效的想法取決於你有多確信你可以是應用程序A已認證。我的直覺告訴我,你正在創造一些大規模的攻擊面,以欺騙應用B來相信應用A的身份驗證將比打破實際身份驗證機制容易得多。此外,如果您無法檢測到任何身份驗證詳細信息,則無法提取用戶ID,從而嚴重限制了App B和App C可以提供的功能。我的建議是通過聯合解決方案將認證與App A的開發人員分開和/或與之聯繫。 – 0x90

相關問題