Upgrade to PRO for Only $50/Year—Limited-Time Offer! 🔥

OAuth2.pdf

Samuele
January 15, 2020

 OAuth2.pdf

OAuth2.0: an introduction

Samuele

January 15, 2020
Tweet

More Decks by Samuele

Other Decks in Programming

Transcript

  1. “Treat your password like your toothbrush. Don't let anybody else

    use it, and get a new one every six months.” Clifford Stoll
  2. THE ISSUE (OF GIVING TO 3rd PARTY YOUR PASSWORD) •

    Password stored in clear-text. • Servers are required to support password authentication, despite the security weaknesses inherent in passwords. • Third-party applications gain overly broad access to the resource owner's protected resources, leaving resource owners without any ability to restrict duration or access to a limited subset of resources. • Resource owners cannot revoke access to an individual third party without revoking access to all third parties, and must do so by changing the third party's password. • Compromise of any third-party application results in compromise of the end-user's password and all of the data protected by that password.
  3. “The OAuth 2.0 authorization framework enables a third-party application to

    obtain limited access to an HTTP service, either on behalf of a resource owner by orchestrating an approval interaction between the resource owner and the HTTP service, or by allowing the third-party application to obtain access on its own behalf.” https://tools.ietf.org/html/rfc6749
  4. “The OAuth 2.0 authorization framework enables a third-party application to

    obtain limited access to an HTTP service, either on behalf of a resource owner by orchestrating an approval interaction between the resource owner and the HTTP service, or by allowing the third-party application to obtain access on its own behalf.” https://tools.ietf.org/html/rfc6749
  5. “The OAuth 2.0 authorization framework enables a third-party application to

    obtain limited access to an HTTP service, either on behalf of a resource owner by orchestrating an approval interaction between the resource owner and the HTTP service, or by allowing the third-party application to obtain access on its own behalf.” https://tools.ietf.org/html/rfc6749
  6. “The OAuth 2.0 authorization framework enables a third-party application to

    obtain limited access to an HTTP service, either on behalf of a resource owner by orchestrating an approval interaction between the resource owner and the HTTP service, or by allowing the third-party application to obtain access on its own behalf.” https://tools.ietf.org/html/rfc6749
  7. “The OAuth 2.0 authorization framework enables a third-party application to

    obtain limited access to an HTTP service, either on behalf of a resource owner by orchestrating an approval interaction between the resource owner and the HTTP service, or by allowing the third-party application to obtain access on its own behalf.” https://tools.ietf.org/html/rfc6749
  8. OpenID CONNECT “OpenID Connect 1.0 is a simple identity layer

    on top of the OAuth 2.0 [RFC6749] protocol. It enables Clients to verify the identity of the End-User based on the authentication performed by an Authorization Server, as well as to obtain basic profile information about the End-User in an interoperable and REST-like manner.” https://openid.net/specs/openid-connect-core-1_0.html
  9. OpenID CONNECT “OpenID Connect 1.0 is a simple identity layer

    on top of the OAuth 2.0 [RFC6749] protocol. It enables Clients to verify the identity of the End-User based on the authentication performed by an Authorization Server, as well as to obtain basic profile information about the End-User in an interoperable and REST-like manner.” https://openid.net/specs/openid-connect-core-1_0.html
  10. OpenID CONNECT “OpenID Connect 1.0 is a simple identity layer

    on top of the OAuth 2.0 [RFC6749] protocol. It enables Clients to verify the identity of the End-User based on the authentication performed by an Authorization Server, as well as to obtain basic profile information about the End-User in an interoperable and REST-like manner.” https://openid.net/specs/openid-connect-core-1_0.html
  11. GLOSSARY Resource Owner: An entity capable of granting access to

    a protected resource. Resource Server: The server hosting the protected resources. Client: An application making protected resource requests on behalf of the resource owner and with its authorization. The term "client" does not imply any particular implementation characteristics. Access Token: Credentials used to access protected resources. An access token is a string representing an authorization issued to the client. Authorization Server: The server issuing access tokens to the client after successfully authenticating the resource owner and obtaining authorization. Refresh Token: Credentials used to obtain access tokens. Refresh tokens are issued to the client by the authorization server and are used to obtain a new access token when the current access token becomes invalid or expires.
  12. CLIENT RESOURCE OWNER AUTHORIZATION SERVER RESOURCE SERVER AUTHORIZATION REQUEST AUTHORIZATION

    GRANT AUTHORIZATION GRANT ACCESS TOKEN ACCESS TOKEN RESOURCES
  13. CLIENT RESOURCE OWNER AUTHORIZATION SERVER RESOURCE SERVER AUTHORIZATION REQUEST AUTHORIZATION

    GRANT AUTHORIZATION GRANT ACCESS TOKEN ACCESS TOKEN RESOURCES
  14. CLIENT AUTHORIZATION SERVER RESOURCE SERVER AUTHORIZATION GRANT ACCESS TOKEN &

    REFRESH TOKEN ACCESS TOKEN INVALID TOKEN REFRESH TOKEN
  15. CLIENT AUTHORIZATION SERVER RESOURCE SERVER AUTHORIZATION GRANT ACCESS TOKEN &

    REFRESH TOKEN ACCESS TOKEN INVALID TOKEN REFRESH TOKEN ACCESS TOKEN & (OPTIONAL) REFRESH TOKEN
  16. CLIENT REGISTRATION • NOT DEFINED BY THE OAUTH SPEC •

    SPECIFY CLIENT TYPE (SEE NEXT) • PROVIDE REDIRECT URIs • PROVIDE OTHER INFOS (APP NAME, LOGO, …) • CLIENT OBTAINS AN IDENTIFIER (PUBLIC; NEVER USE FOR CLIENT AUTHENTICATION!)
  17. CLIENT TYPES • BASED ON ABILITY TO MAINTAIN THE CONFIDENTIALITY

    OF THEIR CREDENTIALS • CONFIDENTIAL (Backend web app) • PUBLIC (SPA, native app, …)
  18. OBTAINING AUTHORIZATION • AUTHORIZATION CODE GRANT • IMPLICIT GRANT •

    RESOURCE OWNER PASSWORD CREDENTIAL • CLIENT CREDENTIALS
  19. CLIENT RESOURCE OWNER AUTHORIZATION SERVER USER AGENT CLIENT ID &

    REDIRECT URI AUTHE. REQ AUTHE. REQ USER AUTHE.
  20. CLIENT RESOURCE OWNER AUTHORIZATION SERVER USER AGENT CLIENT ID &

    REDIRECT URI AUTHE. REQ AUTHE. REQ USER AUTHE. USER AUTHE.
  21. CLIENT RESOURCE OWNER AUTHORIZATION SERVER USER AGENT CLIENT ID &

    REDIRECT URI AUTHE. REQ AUTHE. REQ USER AUTHE. USER AUTHE. AUTHORIZATION CODE
  22. CLIENT RESOURCE OWNER AUTHORIZATION SERVER USER AGENT CLIENT ID &

    REDIRECT URI AUTHE. REQ AUTHE. REQ USER AUTHE. USER AUTHE. AUTHORIZATION CODE AUTHORIZATION CODE
  23. CLIENT RESOURCE OWNER AUTHORIZATION SERVER USER AGENT CLIENT ID &

    REDIRECT URI AUTHE. REQ AUTHE. REQ USER AUTHE. USER AUTHE. AUTHORIZATION CODE AUTHORIZATION CODE AUTHORIZATION CODE & REDIRECT URI
  24. CLIENT RESOURCE OWNER AUTHORIZATION SERVER USER AGENT CLIENT ID &

    REDIRECT URI AUTHE. REQ AUTHE. REQ USER AUTHE. USER AUTHE. AUTHORIZATION CODE AUTHORIZATION CODE AUTHORIZATION CODE & REDIRECT URI ACCESS TOKEN (& OPTIONAL REFRESH TOKEN)
  25. CLIENT RESOURCE OWNER AUTHORIZATION SERVER USER AGENT CLIENT ID &

    REDIRECT URI AUTHE. REQ AUTHE. REQ USER AUTHE. USER AUTHE.
  26. ACCESS TOKEN REQUEST POST /token HTTP/1.1 Host: server.example.com Authorization: Basic

    czZCaGRSa3F0MzpnWDFmQmF0M2JW Content-Type: application/x-www-form-urlencoded grant_type=authorization_code&code=SplxlOBeZQQYbYS6WxS bIA&redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom% 2Fcb
  27. ACCESS TOKEN REQUEST POST /token HTTP/1.1 Host: server.example.com Authorization: Basic

    czZCaGRSa3F0MzpnWDFmQmF0M2JW Content-Type: application/x-www-form-urlencoded grant_type=authorization_code&code=SplxlOBeZQQYbYS6WxS bIA&redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom% 2Fcb
  28. ACCESS TOKEN REQUEST POST /token HTTP/1.1 Host: server.example.com Authorization: Basic

    czZCaGRSa3F0MzpnWDFmQmF0M2JW Content-Type: application/x-www-form-urlencoded grant_type=authorization_code&code=SplxlOBeZQQYbYS6WxS bIA&redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom% 2Fcb
  29. ACCESS TOKEN REQUEST POST /token HTTP/1.1 Host: server.example.com Authorization: Basic

    czZCaGRSa3F0MzpnWDFmQmF0M2JW Content-Type: application/x-www-form-urlencoded grant_type=authorization_code&code=SplxlOBeZQQYbYS6WxS bIA&redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom% 2Fcb
  30. ACCESS TOKEN REQUEST POST /token HTTP/1.1 Host: server.example.com Authorization: Basic

    czZCaGRSa3F0MzpnWDFmQmF0M2JW Content-Type: application/x-www-form-urlencoded grant_type=authorization_code&code=SplxlOBeZQQYbYS6WxS bIA&redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom% 2Fcb
  31. ACCESS TOKEN RESPONSE HTTP/1.1 200 OK Content-Type: application/json;charset=UTF-8 Cache-Control: no-store

    Pragma: no-cache { "access_token":"2YotnFZFEjr1zCsicMWpAA", "token_type":"example", "expires_in":3600, "refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA", "example_parameter":"example_value" }
  32. ACCESS TOKEN RESPONSE HTTP/1.1 200 OK Content-Type: application/json;charset=UTF-8 Cache-Control: no-store

    Pragma: no-cache { "access_token":"2YotnFZFEjr1zCsicMWpAA", "token_type":"example", "expires_in":3600, "refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA", "example_parameter":"example_value" }
  33. ACCESS TOKEN RESPONSE HTTP/1.1 200 OK Content-Type: application/json;charset=UTF-8 Cache-Control: no-store

    Pragma: no-cache { "access_token":"2YotnFZFEjr1zCsicMWpAA", "token_type":"example", "expires_in":3600, "refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA", "example_parameter":"example_value" }
  34. CLIENT RESOURCE OWNER AUTHORIZATION SERVER USER AGENT CLIENT ID &

    REDIRECT URI AUTHE. REQ AUTHE. REQ USER AUTHE.
  35. CLIENT RESOURCE OWNER AUTHORIZATION SERVER USER AGENT CLIENT ID &

    REDIRECT URI AUTHE. REQ AUTHE. REQ USER AUTHE. USER AUTHE.
  36. CLIENT RESOURCE OWNER AUTHORIZATION SERVER USER AGENT CLIENT ID &

    REDIRECT URI AUTHE. REQ AUTHE. REQ USER AUTHE. USER AUTHE. REDIRECT URI WITH ACCESS TOKEN IN FRAGMENT
  37. CLIENT RESOURCE OWNER AUTHORIZATION SERVER USER AGENT CLIENT ID &

    REDIRECT URI AUTHE. REQ AUTHE. REQ USER AUTHE. USER AUTHE. REDIRECT URI WITH ACCESS TOKEN IN FRAGMENT WEB-HOSTED CLIENT RESOURCE REDIRECT URI (W/O FRAGMENT)
  38. CLIENT RESOURCE OWNER AUTHORIZATION SERVER USER AGENT CLIENT ID &

    REDIRECT URI AUTHE. REQ AUTHE. REQ USER AUTHE. USER AUTHE. REDIRECT URI WITH ACCESS TOKEN IN FRAGMENT WEB-HOSTED CLIENT RESOURCE REDIRECT URI (W/O FRAGMENT) SCRIPT
  39. CLIENT RESOURCE OWNER AUTHORIZATION SERVER USER AGENT CLIENT ID &

    REDIRECT URI AUTHE. REQ AUTHE. REQ USER AUTHE. USER AUTHE. REDIRECT URI WITH ACCESS TOKEN IN FRAGMENT WEB-HOSTED CLIENT RESOURCE REDIRECT URI (W/O FRAGMENT) SCRIPT ACCESS TOKEN
  40. CLIENT RESOURCE OWNER AUTHORIZATION SERVER USER AGENT CLIENT ID &

    REDIRECT URI AUTHE. REQ AUTHE. REQ USER AUTHE. USER AUTHE.
  41. CLIENT AUTHORIZATION SERVER USER AGENT REDIRECT URI WITH ACCESS TOKEN

    IN FRAGMENT WEB-HOSTED CLIENT RESOURCE REDIRECT URI (W/O FRAGMENT)
  42. HISTORICAL REASONS FOR IMPLICIT GRANT • Browsers can manipulate only

    url fragment without causing a page reload (not true anymore since HistoryAPI) • CORS (Authorization Code Flow requires a POST at some point)
  43. ACCESS TOKEN REQUEST POST /token HTTP/1.1 Host: server.example.com Authorization: Basic

    czZCaGRSa3F0MzpnWDFmQmF0M2JW Content-Type: application/x-www-form-urlencoded grant_type=authorization_code&code=SplxlOBeZQQYbYS6WxS bIA&redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom% 2Fcb
  44. CLIENT RESOURCE OWNER AUTHORIZATION SERVER USER AGENT CLIENT ID &

    REDIRECT URI AUTHE. REQ AUTHE. REQ USER AUTHE. USER AUTHE. AUTHORIZATION CODE AUTHORIZATION CODE AUTHORIZATION CODE & REDIRECT URI ACCESS TOKEN (& OPTIONAL REFRESH TOKEN)
  45. CLIENT RESOURCE OWNER AUTHORIZATION SERVER USER AGENT CLIENT ID, REDIRECT

    URI CODE CHALLENGE,CODE CHALLENGE & HASH METHOD AUTHE. REQ AUTHE. REQ USER AUTHE. USER AUTHE. AUTHORIZATION CODE AUTHORIZATION CODE AUTHORIZATION CODE, REDIRECT URI & CODE VERIFIER ACCESS TOKEN (& OPTIONAL REFRESH TOKEN) GENERATE CODE VERIFIER AND ITS HASH (CODE CHALLENGE)
  46. ACCESS TOKEN REQUEST POST /token HTTP/1.1 Host: server.example.com Authorization: Basic

    czZCaGRSa3F0MzpnWDFmQmF0M2JW Content-Type: application/x-www-form-urlencoded grant_type=authorization_code&code=SplxlOBeZQQYbYS6WxS bIA&redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom% 2Fcb
  47. ACCESS TOKEN REQUEST POST /token HTTP/1.1 Host: server.example.com Authorization: Basic

    czZCaGRSa3F0MzpnWDFmQmF0M2JW Content-Type: application/x-www-form-urlencoded grant_type=authorization_code&code=SplxlOBeZQQYbYS6WxS bIA&redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom% 2Fcb&code_verifier=abcd
  48. OBTAINING AUTHORIZATION • AUTHORIZATION CODE GRANT • IMPLICIT GRANT •

    RESOURCE OWNER PASSWORD CREDENTIAL • CLIENT CREDENTIALS
  49. OBTAINING AUTHORIZATION • AUTHORIZATION CODE GRANT (+PKCE) • IMPLICIT GRANT

    • RESOURCE OWNER PASSWORD CREDENTIAL • CLIENT CREDENTIALS