Third Party Authentication/Authorization Hao-Lun Hsu Taiwan Evolutionary Intelligence Laboratory 2016/12/7 Group Meeting Presentation

Outline OpenID OAuth 1.0 OAuth 2.0 Other Third Party Authentication/Authorization Conclusion

Open ID An open standard and decentralized authentication protocol Issued in 2007 傳統上每個網站都要架設自己的帳號密碼系統，對開發 者來說麻煩。 使用者需要記得各個網站的帳號密碼，不方便管理。 Single-Sign On (e.g. NTU SSO) Open ID is an implementation of SSO 去中心化：網絡內容不是由專業網站或特定人群所產生，而是由全體網民共同參與、權級平等的共同創造的結果。任何人，都可以在網絡上表達自己的觀點或創造原創的內容，共同生產信息。

Open ID: Mechanism Terminology: End User: 需要向網站表明身分的人 Identity Provider(IdP): 提供Open ID驗證服務的提供者 e.g. NTU SSO Relying Party(RP): 要對End User的標識進行驗證的網站 e.g. Ceiba

Open ID: Process Flow RP User IdP (A) Access RP (B) Open ID Identifier (C) Discovery (D) Response (E) Redirect to Open ID Provider (E) Access Open ID Provider with Redirect url (F) User Credentials (password) (G) Verify Credentials (I) Allow Access (H) Redirect to RP with IdP Credentials (H) (J) Protected Data

Open ID: Security Issue Authentication bug Phishing Authentication hijacking in unsecured connection

Authentication Bug IdP RP Attacker Fake Request Identity Check Signature (no ask for the user's email address) Identity with Fake Email Address RP Attacker data R. Wang, S. Chen, X.F. Wang, “Signing Me onto Your Accounts through Facebook and Google: a Traffic-Guided Security Study of Commercially Deployed Single-Sign-On Web Services “, 2012

Phishing malicious RP fake IdP Victim Access Request Redirect User Credentials 解決方法： 注意瀏覽器小鎖頭憑證 Victim

Authentication Hijacking in Unsecured Connection IdP Attacker Sniff Authenticate Identity Data Access Data with Identity Sniff the wire RP Victim

Authentication Hijacking in Unsecured Connection Use nonces (an number used once): Only works if the user is the first one to use the URL Use of TLS/SSL in the authentication process nonce is an arbitrary number that may only be used onc OpenID 結束

OAuth 有一個第三方應用程式希望存取你的Facebook中的好 友名單，該如何做到？ OAuth is an open standard for authorization Let users authorize some applications to access their information on the other websites without giving them the passwords Issued in 2007 (OAuth 1.0), 2009 (OAuth 1.0a) and 2010 (OAuth 2.0) Blaine Cook Chris Messina Larry Halff

OAuth 1.0: Mechanism Terminology: Service Provider: OAuth服務的提供者 e.g. Facebook Connect User: 在Service Provider上有個帳號的使用者 Consumer: 需要取得User授權，並存取其資源的程式 /網站

OAuth 1.0: Mechanism User (A) Obtaining a Request Token Con-sumer Service Provider (B) Request Token (Unauthorized) (D) Authenticate (with Callback URI) (C) Request Token User (E) Request Token (Authorized) (E) Redirect 讓service provider發行一個access token取代password Client id in header, body, query parameter Request Token in Body (F) Obtaining an Access Token (G) Access Token

OAuth 1.0: Security issue 竄改Callback URI: Attacker先初始化一個合法的Request Token，然後誘 騙Victim向這個Request Token授權。竄改Victim向 Service Provider發起的授權請求中的Callback URI，使得 授權過後的Request Token轉到Attacker指定的網站。 Attacker再將已授權的Request Token送回Consumer完成 授權流程。

OAuth 1.0a: Mechanism Signature Con-summer Service Provider User (A) Obtaining a request token (with callback url) Signature Con-summer Service Provider (B) Request token (Unauthorized) (D) Authenticate (with callback url) (C) Request token User Verify cb url (E) Request token (Authorized) (with verifier) (E) Redirect 缺點: (C) (D) (F)要簽名 (F) Obtaining an access token (with verifier) (G) Access token

OAuth 1.0a: Disadvantage Unfriendly to non-browser based applications 2.0: new ways for an application to get authorization for a user Signature: complicate to developer 2.0: Use SSL/TLS Life of access tokens are too long 2.0: short-lived access token and refresh token 1. User credential

OAuth 2.0 Terminology: Resource Owner: 可以授權別人去存取 Protected Resource Resource Server: 存放 Protected Resource 的伺服器。根據 Access Token 來接受 Protected Resource 的請求。 Client: 代表 Resource Owner 去存取 Protected Resource 的 應用程式。 Authorization Server: 授權服務的提供者。

OAuth 2.0: Abstract Protocol Flow Resource Owner Client Authorization Request Authorization Grant Authorization Server Authorization Grant Access Token Access Token Resource Server Protected Resource

OAuth 2.0: Mechanism There are 4 grant types: Access token: a string Authorization Code Grant Flow Implicit Grant Flow Resource Owner Password Credentials Grant Flow  Client Credentials Grant Flow  Access token: a string identifier, scope, expired time… Refresh token: to obtain a new access token

Authorization Code Grant Flow (B) (A) Client Identifier, Scope, Redirection URI User Agent Authorization Server (B) User authenticates (C) Authorization Code Resource Owner (A) (C) (C) code要短時效(10分鐘)、只能用一次 e.g. https://client.example.com/cb?code=SplxlOBeZQQYbYS6WxSbIA &state=xyz (D) 用POST Redirect uri要和(A)一樣 需要跟AS驗證Client的身分 (D) Client ID, Authorization Code, Redirection URI Client (E) Access Token, Refresh Token(optional)

Authorization Code Grant Flow 要向 Authorization Server 先取得 Grant Code 再取得 Access Token （兩步）。 適合 Confidential Clients ，如部署在 Server 上面的應 用程式。 需要 User-Agent Redirection。 Security issue: Authorization Code 被偷: Use TLS Authorization Code 被二度利用: Code要短時效、一次性 竄改 Redirection URI: 事先設定 Redirection URI 並驗證 Confidential Clients: Client 可以自我保密 client 的 credentials（例如跑在 Server 上面，且可以限制 credentials 的存取） public：Client 無法保密 credentials （Native App 或是跑在 Browser 裡面的 App）

Implicit Grand Flow Authorization Server User Agent Client (A) Client Identifier, Scope, Redirection URI User Agent Authorization Server (B) User authenticates (C) Redirection URI with Access Token in Fragment (A) Client Web-Hosted Client Resource (D) Redirection URI without Fragment (C) Access token is in fragment (E) Script (F) Access Token Resource Owner (B)

Implicit Grand Flow Authorization Server 直接向 Client 核發 Access Token （一步）。 適合非常特定的 Public Clients ，例如跑在 Browser 裡 面的應用程式。 Authorization Server 不必（也無法）驗證 Client 的身 份。 禁止核發 Refresh Token。 Public client: 沒有自己的後端處理器，所以仰賴前端、User的 Agent來處理程式碼、轉址等等，故無法守住自己的credential。

Resource Owner Password Credentials Grant Flow Client Resource Owner (A) Resource Owner Password Credential Authorization Server (B) Resource Owner Password Credential (C) Access Token, Refresh Token (optional)

Resource Owner Password Credentials Grant Flow 風險較高，因為會讓Client看到帳號密碼(一個不 必要的行為)。 Resource Owner 沒辦法控制Client要求授權的範 圍。 只適合Resource Owner 高度信賴 Client ，例如 作業系統內建的應用程式。 e.g. HTC sense 存取 Facebook

Client Credentials Grant Flow Authorization Server (A) Client Authenticate (B) Access Token Client 自己就是 Resource Owner ，Client 取用的是自己擁有 的 Protected Resources。

Other Third-Party Authentication/Authorization Open ID Connect (OIDC) 身分認證 + OAuth 2.0 提供RP有關認證者的資料 SAML An XML-based, open-standard data format for exchanging authentication and authorization data between parties 可以跟OpenID 合用 e.g. NTU SSO

(No longer supported since 2015) Open ID OAuth 2.0 Open ID Connect Facebook V (Facebook Connect) Google (No longer supported since 2015) Yahoo Microsoft (Azure AD Connect) IBM (Blue ID) Twitter

Conclusion Open ID and OAuth are widely used nowadays. Understanding these standards helps us figure out how applications which can be signed in with your Facebook/Google accounts work.

Reference Wikipedia: Stackoverflow: https://en.wikipedia.org/wiki/OpenID https://en.wikipedia.org/wiki/OAuth Stackoverflow: http://stackoverflow.com/questions/4113934/how-is-oauth-2-different-from-oauth-1 http://stackoverflow.com/questions/23780909/why-does-the-implicit-authorization-grant-in-oauth-require- a-web-hosted-client http://stackoverflow.com/questions/14574846/client-authentication-on-public-client https://spin.atomicobject.com/2016/05/30/openid-oauth-saml/ http://openid.net/connect/ http://huoding.com/2011/11/08/126 https://blog.yorkxin.org/2013/09/30/oauth2-1-introduction https://tools.ietf.org/html/rfc6749 https://oauth.net/core/1.0/ https://oauth.net/core/1.0a/