EZoAuth
建立安全便捷的網路與系統環境
#統一管理數位身分
#安全掌握資訊存取
#多系統操作順暢快
應用程式使用現況與問題
小劇場一
第三方應用程式
授權伺服器
.png)
使用者
：可以給我使用者的隱私資料嗎？
：可以啊！但你需要先給我使用者的帳號與密碼。
：可以給我你的帳號與密碼嗎？因為我想要你的資料。
.png){kind=small}
：這種個人的隱私資訊是可以說給就給的嗎？
：..........
衍生問題一
資料外流發生
應用程式所存取的密碼通常是明文 (Plaintext)，資料遭非法存取時，使用者的密碼與資料將外流。
缺乏權限控制
應用程式會獲得近乎完整的使用權限，可存取受保護的資料，但使用者無法限制應用程式可存取資料的時限與範圍。
無法撤銷存取
使用者無法撤銷應用程式的存取權限，必須藉由更改使用者之密碼，才可執行。
安全風險惡化
當任何應用程式被破解，都將導致使用者的密碼和所有受該密碼保護的資料被破解。
小劇場二
.png)
.png)
使用者2
使用者1
.png)
使用者3
：工作執行都在不同的系統中作業，頻頻切換畫面，真的好花時間！
.png){kind=small}
：而且每次登入都需要輸入帳號與密碼，系統多密碼就多，好容易忘記！
.png){kind=small}
：告訴你們一個方法，我都設定成相同的密碼，這樣就不怕忘記啦！
：這樣真的好嗎…？
衍生問題二
用戶體驗下降
使用者必須在多系統之間切換，可能會感到疲惫與不便。
登入過程繁瑣
每次訪問系統都須單獨登入，徒增使用者的操作負擔與時間消耗。
密碼管理困難
需記憶多組不同系統的帳號與密碼，可能導致密碼遺忘或混淆。
系統安全威脅
使用者為了方便而設定相同密碼，一旦其中一個系統遭受到安全威脅，其他系統也可能受影響。
EZoAuth 有效解決以上問題！
導入 EZoAuth 為企業打造安全便利的網路環境，提供 OAuth2.0 業界標準開放授權協定，透過安全的身份授權機制，避免將用戶的帳號密碼直接傳遞給第三方應用程式，並掌握所有授予第三方應用程式的資源存取權限。
除此之外，還可以與市場上大多數的產品、服務、技術框架無痛整合，更加入 SSO 單點登入機制，進一步提升用戶操作體驗，減少密碼管理的負擔及繁瑣的登入過程。
EZoAuth 讓效益最大化
EZoAuth 除了為企業帶來多樣好處，也讓管理者、使用者與 IT 人員在作業中達到超高效率！
管理者
保護公司的資訊資產
遵循法規與落實資安規定
降低密碼安全事件風險
提高員工與 IT 人員生產力
降低 IT 維運成本
使用者
簡化過多的帳號與密碼
簡化訪問平台的前置作業
避免重複登入各應用程式
提升忘記密碼的處理時效
強化身分認證的安全性
IT 人員
減少資訊服務台相關諮詢
集中管理用戶的身分認證與權限
快速解決幽靈帳號問題
簡化應用程式的開發
任何應用程式執行統一安全政策與規定
EZoAuth 優勢與特色
提供單點登入
提供 OAuth 2.0 標準協定，用戶只需登入一次，即可進入已被授權訪問的所有應用程式。
提供用戶行為分析
提供用戶操作與存取的記錄，可以查看並分析用戶的所有行為。
支援 OAuth 單點註銷
用戶在使用 OAuth 用戶端登出時，會自動從 OAuth 伺服器登出。
提供友善開發工具
提供 Sever 端應用註冊、Client 端參數設置，以及 Spring Framework 客製開發介面串接自有服務
提供權限管控
提供集中式管理後台，控管所有用戶的登入權限，在權限許可下提供用戶系統中配置的資料與功能。
強化帳戶安全
利用 HTTPS 保密傳輸所有資料，再以不可逆演算法加密儲存，結合 EZoID 提供的無密碼登入，以強化帳號的安全性。
整合 AD 帳號
支援 LDAP 與 Active Directory 伺服器，只需要幾行代碼即可快速整合已有帳號體系。
OAuth2.0 小教室
什麼是 OAuth2.0？
OAuth 2.0 是一種授權通訊協定，授與應用程式對資源的安全存取權。當使用者 (Resource Owner) 操作應用程式 (Client) 時，向身份認證服務 (Authorization Server) 認證並取得權限，無需共用實際的使用者驗證資訊，例如使用者名稱和密碼，再允許應用程式以此權限請求使用者擁有的資源。
OAuth2.0 vs. OAuth1.0
使用簽名金鑰（token secret）和權杖金鑰（token key）來進行授權驗證
採用三步授權流程（request token -> user authorization -> access token），需要使用者在授權過程中輸入用戶名和密碼，比較繁瑣
使用了 HMAC-SHA1 演算法對每個請求進行簽名，確保請求的完整性和安全性
適用於單個 API 的授權
適用於多個 API 的授權
使用 HTTPS 協定來保護授權請求和回應，確保通信的安全性
採用四步授權流程（authorization code -> access token -> refresh token -> protected resource），使用者只需在第一步輸入用戶名和密碼即可，授權過程更加簡單
使用訪問權杖（access token）和刷新權杖（refresh token）來進行授權驗證
OAuth2.0 比 OAuth1.0 更加靈活和可擴展，可以根據需要添加新的授權方式和授權範圍
OAuth1.0
OAuth2.0
授權方式
授權流程
安全性
適用範圍
可擴展性
綜合上述，OAuth2.0 較 OAuth1.0 更加簡單、靈活和安全，支持多個 API 的授權，因此越來越多的網站和應用程式採用 OAuth2.0 協定來進行使用者授權。
OAuth2.0 協議流程圖
A
B
C
D
E
F
Client 端向 Resource Owner 發送 Authorization request (授權請求)。
Resource Owner 給予 Client 端 Authorization grant (授權許可)。
Client 端向 Authorization server 請求 Access token (訪問令牌)，雙方進行身分認證，Client 端也同時出示 Authorization grant (授權許可)。
Authorization server 向 Resource Owner 驗證 Client 的身份與授權許可，若合法，則簽發 Access token (訪問令牌) 給予 Client 端。
Client 端取得 Access token (訪問令牌) 後，再向 Resource server 請求 Protected resource (受保護資料)，並出示 Access token (訪問令牌) 進行身份驗證。
Resource server 驗證來自 Client 端傳送的 Access token (訪問令牌)，若合法，則回傳 Protected resource (受保護資料) 給 Client 端。