Please enable JavaScript.

Coggle requires JavaScript to display documents.

OAuth2.0 - Coggle Diagram

- - - - bad bad bad, big no no no
        
        It is not secured, if data leakage happens.
        
        You cannot deny anything that user can do (cannot do read only for e.g.)
  - - - no standards
      - expiration
        
        if key gets stolen a robber can use this key indefinitely!
        
        experation date is a solution but very uncomfortable one
  - - - Authorization framework (means standards)
      - scope access (for e.g. read only)
      - OAuth2.0 is specifically built for HTTP APIs
      - "delegation protocol"
      - separation of user & client credentials
- - - - Can keep a secret
    - - this type of client cannot keep a secret (e.g. browser or mobile device)
- - - - https://authserver.example.com/authorize
        
        ?response_type=code
        
        signals that authorization request wants to use authorization code flow
        
        &client_id=12345
        
        unique identifier for client application (?)
        
        Client Secret
        
        SHOULDN'T be given to native, browser apps for security issues
        
        &redirect_uri=https://client.example.com/callback
        
        this is uri that is used for returning response to client
        
        auth server redirects to this uri once it gets consent from authenticated resource owner (user)
        
        &state=xyz
        
        this data will be attached in response (&redirect_uri), not guessable
        
        &scope=api1.read
        
        what permission you do want
    - - https://client.example.com/callback
        
        ?code=OSidmNSjdfvnlKSd
        
        represents user consents and authorization
        
        short lifetime
        
        ?state=xyz
        
        must match the value in authorization request
    - - POST /token HTTP/1.1
        
        Host: server.example.com Content-Type: application/x-www-form-urlencoded Authorization: Basic SLmpoWdg0S9d9gik (if not exists then client_id and client_secret param)
        
        grant_type=authorization_code
        
        shows that we want to do this in authorization code flow
        
        &code=OSidmNSjdfvnlKSd
        
        &redirect_uri=https://client.example.com/callback
        
        &client_id=skduhrkgjtn&client_secret=o3intklsjdkf
        
        if authorization basic does not exists in headers
    - - Basic Authentication Style (RFC 7617)
        
        Base64(client_id + ":" + client_secret)
      - OAuth Style (RFC 6749)
        
        Base64(urlformencode(client_id) + ":" + urlformencode(client_secret))
    - - JSON
        
        HTTP/1.1 200 OK Content-Type: application/json { "access_token": "skjf98Uojodsrgt", "token_type" : "Bearer", "expires_in": 3600, "scope": "api1.read" }
    - - this is technique that can ensure that exchanged code is meant for us and we can validate this
      - code_challenge
        
        This encrypted string by client is sent to auth server
      - code_verifier
        
        to switch authz code to access token you need to send plain unencrypted string to server
      - Protects from authz code theft & authz code interception
  - - - Request
        
        https://authserver.example.com/authorize
        
        ?response_type=token
        
        &client_id=Sksjdfi394
        
        &redirect_uri=https://client.example.com/callback
        
        &scope=api1.read
        
        &state=xyz
      - Response
        
        https://client.example.com/callback
        
        #access_token=qwer2342ert32
        
        &token_type=example
        
        &expires_in=3600
        
        &state
    - - third party JS can stole tokens from URL
      - Access token is exposed to Resource Owner
      - No guarantee that it is the token for the user
      - OpenID extends OAuth Implicit Grant Type and makes the Implicit flow more secure
  - - - Request
        
        POST /token HTTP/1.1 Host: server.example.com Content-Type: application/x-www-form-urlencoded Authorization: Basic LSKjdojntjowjlsKJLdsjlf
        
        # Body grant_type=client_credentials &scope=api.read
      - Response
        
        HTTP/1.1 200 OK Content-Type: application/json { "access_token" : "sdfjskhlk", "token_type": "Bearer", "expires_in" : 3600, "scope": "api1.read" }
- - - - Add to request scope offline_access
    - - in JSON returns also new field refresh_token
  - - - grant_type=refresh_token &refresh_token=<refresh_token> &scope=api1
        
        set grant_type to refresh_token, give refresh_token and same scope as refresh_token
    - - new token and if requested new refresh_token
- - - - Resource Owner grants authorization to client app
        
        Client app (with authorization) gives granted authorization to Authorization server
        
        Authorization server gives Access token to Client app
        
        Client app send request with Access token to Protected resource
        
        Protected resource checks validity of Access token (in some way)
        
        Protected resource sends response to client app
        
        1 more item...
- - - - Resource owner grants Access Token to Client App
        
        Client App sends request with Access Token to Protected Resource
        
        Protected resource checks validity of Access token
        
        Protected resource sends response to client app