Introduction to OAuth 2.0

Michał Pipa

PHPCon Poland, Szczyrk, 27 October 2013

About me

This talk is about securing web services

OAuth 2.0

Authorization framework

RFC 6749

October 2012

The old way

Authorization: Basic dXNlcjpwYXNzd29yZA==

Problems with passwords

  • Third-party apps are required to store passwords for future use (plain text)
  • Servers are required to support password authentication
  • Third-party apps have full access to resource owner's resources
  • To revoke access resource owner must change password
  • Compromise of any third-party application results in compromise of the end-user's password

Solution: OAuth 2.0

  • Uses access tokens
  • Introduces authorization layer
  • Separates role of client from resource owner
  • Uses scopes to restrict access
  • Resource owner can revoke access form one specific app

Who uses OAuth 2.0?

  • Facebook
  • GitHub
  • LinkedIn
  • Twitter
  • and many more...

Roles

Client

Third-party app which is accessing resource server data

Resource owner

The person who is giving third-party app access to his/her resources

Resource server

The server hosting protected resources (API)

Authorization server

The server issuing access tokens to the client (often the same as resource server)

Client types

  • confidential
  • public

Client types

  • web application
  • user-agent-based application
  • native application

Client authentication

  • client_id
  • client_secret

Access token scope

Allow the client to specify the scope of the access request

Protocol Flow

         +--------+                               +---------------+
         |        |------ Authorization Request ->|   Resource    |
         |        |                               |     Owner     |
         |        |<------ Authorization Grant ---|               |
         |        |                               +---------------+
         |        |
         |        |                               +---------------+
         |        |------- Authorization Grant -->| Authorization |
         | Client |                               |     Server    |
         |        |<--------- Access Token -------|               |
         |        |                               +---------------+
         |        |
         |        |                               +---------------+
         |        |---------- Access Token ------>|    Resource   |
         |        |                               |     Server    |
         |        |<------- Protected Resource ---|               |
         +--------+                               +---------------+

Authorization grant

Credential representing the resource owner's authorization

Authorization code

The client directs the resource owner to an authorization server, which directs back to the client with the authorization code

Authorization grant request

GET /authorize?response_type=code&client_id=s6BhdRkqt3&state=xyz
    &redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb HTTP/1.1

Authorization grant response

HTTP/1.1 302 Found
Location: https://client.example.com/cb?code=SplxlOBeZQQYbYS6WxSbIA
          &state=xyz

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=SplxlOBeZQQYbYS6WxSbIA
        &redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb

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"
        }

Implicit

The client is issued access token directly

Simplified flow, used in JavaScript

Implicit authorization request

GET /authorize?response_type=token&client_id=s6BhdRkqt3&state=xyz
    &redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb HTTP/1.1
Host: server.example.com

Implicit authorization response

HTTP/1.1 302 Found
Location: http://example.com/cb#access_token=2YotnFZFEjr1zCsicMWpAA
          &state=xyz&token_type=example&expires_in=3600

Resource owner password credentials

The resource owner credentials are used directly to obtain an access token

Password credentials request

     POST /token HTTP/1.1
     Host: server.example.com
     Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
     Content-Type: application/x-www-form-urlencoded

     grant_type=password&username=johndoe&password=A3ddj3w

Client credentials

The client credentials are used directly to obtain an access token

Used when the client is acting on its own behalf

Client credentials request

         POST /token HTTP/1.1
         Host: server.example.com
         Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
         Content-Type: application/x-www-form-urlencoded

         grant_type=client_credentials

Access token

  • Credentials used to access protected resources
  • String representing an authorization issued to the client
  • Represent specific scopes and durations of access

$ curl -H "Authorization: Bearer MjAyNTYyNDE5YmI2MTk4OTE" https://api.example.com/resource

Refresh token

  • Credentials used to obtain access tokens
  • Issued to the client by the authorization server
  • Credentials used to obtain a new access token when the current access expires

Refreshing an Expired Access Token

+--------+                                           +---------------+
|        |------------ Authorization Grant --------->|               |
|        |                                           |               |
|        |<--------------- Access Token -------------|               |
|        |               & Refresh Token             |               |
|        |                                           |               |
|        |                            +----------+   |               |
|        |--------- Access Token ---->|          |   |               |
|        |                            |          |   |               |
|        |<----- Protected Resource --| Resource |   | Authorization |
| Client |                            |  Server  |   |     Server    |
|        |--------- Access Token ---->|          |   |               |
|        |                            |          |   |               |
|        |<----- Invalid Token Error -|          |   |               |
|        |                            +----------+   |               |
|        |                                           |               |
|        |---------------- Refresh Token ----------->|               |
|        |                                           |               |
|        |<--------------- Access Token -------------|               |
+--------+           & Optional Refresh Token        +---------------+

Case study

Case study: requirements

  • Mobile app (iOS and later Android)
  • Third-party app integration
  • REST API (PHP, Symfony, FOSOAuthServerBundle)
  • All data fetched from API
  • Users can register and login using Facebook and LinkedIn
                +-------------+         +-----------+
                |             |         |           |
                |             |+------->| Facebook  |
                |             |         |           |
                |             |<-------+| LinkedIn  |
                |             |         |           |
                |             |         |           |
                | Mobile apps |         |           |
                |             |         |           |
                |             |         |           |
                |             |         +-----------+
                |    iOS      |
                |             |         +-----------+
                |   Android   |         |           |
                |             |+------->|           |
                |             |         | Backend   |
                |             |<-------+|           |
                |             |         |           |
                |             |         |           |
                |             |         |           |
                |             |         |           |
                +-------------+         +-----------+

Case study: solution

  • Custom authorization grant type
  • Facebook/LinkedIn OAuth access token as authorization grant

Summary

Don't reinvent the wheel!

Use OAuth 2.0

Questions

Please rate my talk

https://joind.in/talk/view/9776

Thank you!