Skip to content

Instantly share code, notes, and snippets.

@misho-kr

misho-kr/Learn OAuth 2.0 - Get started as an API Security Expert.md

Last active March 5, 2024 19:51
Show Gist options
  • Save misho-kr/e3bd55625cea422c58e004a39e7d49fb to your computer and use it in GitHub Desktop.
Save misho-kr/e3bd55625cea422c58e004a39e7d49fb to your computer and use it in GitHub Desktop.
Download ZIP
Summary of 'Learn OAuth 2.0 - Get started as an API Security Expert" course on Udemy.Com
Raw
Learn OAuth 2.0 - Get started as an API Security Expert.md

Learn OAuth 2.0 - Get started as an API Security Expert

  • OAuth Terminology: Actors, Endpoints, Tokens
  • Choose the correct OAuth Flow flow for your use-case and apply OAuth Best Practices
  • Protect your APIs and Cloud Solutions with OAuth
  • Access Google, Paypal, LinkedIn and Facebook APIs, and in Mobile Apps (client-side)

Created by Matthias Biehl

OAuth Big Picture

  • Example of using OAuth for third party access
    • How can the third party app access password-protected resources
  • Password Antipattern
    • The app prompts for password, user enters it and the app uses for authentication
    • User does not want to provide the password to the third party app, sharing passwords is bad
    • The app can use it for all sorts of purposes, beyound the immediate need and later in time
  • Solution provided by OAuth 2.0
    • Additional actor is OAuth Server
    • Client -> OAuth Server -> Resource Owner (user) -> OAuth Server -> Client
    • Client -> Resource Server -> oAuth Server
  • OAuth 2.0 is a standard for delegating the access to resources via HTTP protocol without providing the password
  • OAuth version 1 and OAuth 2.0

OAuth Components

  • OAuth Actors
    • OAuth provider
      • authentication component, login page, identity provider
      • consent server
      • token management infrastructure, a database of some sort
    • Resource Provider
      • Manages protected resources and provides access to authorized users
      • Checks the validity of the provided token
    • Resource Owner
      • User owns and can access the data, wants to access the data indirectly through the client
      • Holds the credentials
    • Client
      • The thrid party wants to access the data on behalf of the user
      • Gets and holds Access Token and Refresh Token
      • Identified via ClientID and ClientSecret
  • OAuth Server Endpoints
    • GET /auth returns:
      • Authorization Code (for Authorization Code Grant)
      • Access Token (for Implicit Grant)
    • POST /token
      • Proteced resource, requires Authorization: Basic ClientID:ClientSecret
      • Returns Access Token and Refresh Token (except for Implicit Grant)
    • /verify is not standardized, only internally accessible by Resource Server
    • The URLs and Paths are not standardized
  • OAuth Endpoints
    • Authorization
      • Input Query Parameters: state, scope, response_type, client_id, redirect_uri
      • Output delivered via query parameters in the redicrect URI
        • Authorization Code (for Authorization Code Grant)
        • Access Token (for Implicit Grant)
    • Token
      • Requires Authorization: Basic ClientID:ClientSecret
      • Input Query Parameters: grant_type, code, client_id, redirect_uri
      • Output is Access Token and Refresh Token
    • Redirect
      • Part of the client where authorization information is sent
      • Input Query Parameters: state, scopes, code
    • Resource
      • Requires Authorization: Bearer AccessToken
  • Tokens
    • Must be kept confidentials because they confer access grants -- bearer tokens
    • Have limit validity time period
    • Access Token and Refresh Token
    • Authorization Code is a confirmation of successful authentication and concenting to the access request
  • Credentials
    • Resource owner Credentials
    • Client Credentials: ClientID and ClientSecret
    • Access Token, Refresh Token and Authorization Code
  • Client Registration
    • At registrtaion provides to OAuth Provider Redirect URI and Required Scopes
    • Receives ClientID and ClientSecret

OAuth Flows: Interaction between the OAuth Components

  • Clients sends to OAuth Server the types of resources it wants to access, plus state
  • OAuth Server sends the user to logging service and censent service
  • OAuth Server sends Authorization Code or Access Code to the client
  • Client sends the Access Token with the request to the Resource Server
  • The Resource Server asks the oAuth Server to validate the Access Token
  • The interaction between actors and components is described by authorization flows
    • Authorization Code Grant aka 3-legged flow, most secure one, client must have secure storage
    • Implicit Grant , client does not have secure storage, like client-side Javascript, can not use Refresh Token
    • Client Credentials Grant aka 2-legged flow, the client is also the Resource Owner
    • Resource Owner Password when the resource Owner can entrust the password to the client

Authorization Code Flow

  • 3-legged flow that enables checking the identity of the 3 involved actors
    • Secure storage is needed by the client to store tokens, client-id and client-secret
    • Allows to have tokens that live longer so it does not require the resource owner to enter the password often
    • The password is exchanged only between the Resource Owner and OAuth Server
  • Authorization Flow
    • Resource Owner calls Client which redirects to OAuth Server
      • response_type=code, scope, state, client-id, redirect-uri
    • OAuth Server presents a Login Page and then a Concent Page
    • OAuth Server returns to the browser with a redirect (302) to the redirect-uri which is handled by the Client
      • The redirect url contains an Authorization Code
      • That code is valid for short period of time -- couple of minutes
  • Token Flow
    • Client calls /token endpoint of the OAuth Server with POST method
      • Basic Authorization of the client with client-id and client secret
      • Request body is grant_type=authorization_code and the authorization code
      • Response has Access Token, Refresh Token, token-type and token expiration duration
  • Resource Flow
    • Bearer Authorization with the Access Token
    • Resource Server calls the OAuth Server to verify the token

Authorization Code Flow: Refresh Tokens

  • The Refresh Token is saved by the Client, is valid for longer time than Access Token
  • Password is not required
  • Client calls /token endpoint of the OAuth Server with POST method
    • Basic Authorization of the client with client-id and client secret
    • Request body is grant_type=refresh_token and the Refresh Token
    • Response has new Access Token, Refresh Token, token-type and token expiration duration

Implicit Flow

  • Simplification of the Authorization Code Flow that:
    • Client does not have secure storage for the Refresh Token, ClientID and ClientSecret
    • Does not use the /token endpoint and Refresh Token
    • The call to /auth endpoint returns Access Token
  • The Access Token is valid for shorter time

Client Credentials Flow

  • Simplification of the Authorization Code Flow that:
    • There is no Resource Owner, so Client and Resource Owner are the same
    • Does not require the Resource Owner to authenticate
    • Does not use the /auth endpoint
  • The client needs secure storage for Access Token, Refresh Token, ClientID and ClientSecret

Resource Owner Password Credentials Flow

  • Simplification of the Authorization Code Flow that:
    • The Resource Owner trusts the Client and is willing to share her credentials
    • Does not use the /auth endpoint
  • Acceptable when the Client and the Resource Server are offerred by the same organization
  • The Client must not store the credentials of the Resource Owner
    • Credentials should be used only to get Access Token and Refresh Token
    • Credentials should be deleted immediately after the tokens are procured

OAuth vs OpenID Connect

  • OAuth is used to ensure the privacy of the Resource Owner
  • OpenID Connect standardizes how apps can access the attributes of the Resource Owner via a token
  • OpenID Connect extends the authorization code flow
    • Introduces new tokens
    • Standardizes some endpoints
  • OpenID Connect is realized as an extension of OAuth, as a so-called OAuth profile

Using OAuth to access Facebook

  • Register the client app
  • Call the OAuth endpoints to acquire Authorization Code and Access Token
  • Make Facebook API call with the Access Token
  • Facebook docs: Manually Build a Login Flow
OAuth Worksheet:

- Documentation and Prerequisites
- Client Registration
  - https://developers.facebook.com/
- Authorization Endpoint
  - https://www.facebook.com/v6.0/dialog/oauth?
      client_id=clientId&redirect_uri=URLENCODE(redirectURI)&state=987654321
- Token Endpoint
  - curl -ik "https://graph.facebook.com/v6.0/oauth/access_token?
      redirect_uri=URLENCODE(redirectURI)&client_id=clientId&client_secret=clientSecret&code=code"
- Resource Access
  - curl -H "Accept: application/json" -H "Authorization: Bearer access_token" \
      "https://graph.facebook.com/me"

Using OAuth to access Linkedin

Using OAuth to access GMail and other Google Products

Using OAuth to access PayPal

FAQ: OAuth on Mobile

Final Mission

Conclusion

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment