AUTH GONE SOUTH

César Silva

BSides Lisbon

{
  "alg": "none",
  "typ": "JWT"
}.
{
  "name": "César Silva",
  "email": "mail@apl3b.com",
  "role": "AppSec Guy",
  "twitter": "Apl3b",
  "company": "Farfetch",
  "location": "Porto"
}

OAuth 2.0 & OIDC

AuthN & AuthZ

Common Pitfalls

Scenarios

Authentication

(AuthN)

The act of confirming the truth of an attribute of a single piece of data claimed true by an entity

Factors

  • Knowledge (ex.: password)

  • Ownership (ex.: key)

  • Inherence (ex.: fingerprint)

Authorization

(AuthZ)

The function of specifying access rights/privileges to resources

Access Control Models

  • Role-based (RBAC)

  • Attribute-based (ABAC)

OAUTH 2.0

Open Authorization (v2)

<a href="https://tools.ietf.org/html/rfc6749"/>

OIDC

Open ID Connect

<a href="https://openid.net/specs/openid-connect-core-1_0.html"/>

(Authentication)

     +--------+                               +---------------+
     |        |--(A)- Authorization Request ->|   Resource    |
     |        |                               |     Owner     |
     |        |<-(B)-- Authorization Grant ---|               |
     |        |                               +---------------+
     |        |
     |        |
     |        |
     | Client |
     |        |
     |        |
     |        |
     |        |
     |        |
     |        |
     |        |
     +--------+

<a href="https://tools.ietf.org/html/rfc6749#section-1.2"/>

Protocol Flow

                               +---------------+
--(C)-- Authorization Grant -->| Authorization |
                               |     Server    |
<-(D)----- Access Token -------|               |
                               +---------------+
                               +---------------+
--(E)----- Access Token ------>|    Resource   |
                               |     Server    |
<-(F)--- Protected Resource ---|               |
                               +---------------+

Roles

  • Resource Owner

  • Authorization Server

  • Resource Server

Clients

An application making protected resource requests on behalf of the resource owner* and with its authorization.

* aka User (or Customer)

<a href="https://tools.ietf.org/html/rfc6749#section-1.1"/>

Client Types

  • Confidential

  • Public

<a href="https://tools.ietf.org/html/rfc6749#section-2.1"/>

Clients capable of maintaining the confidentiality of their credentials

Confidential Clients

<a href="https://tools.ietf.org/html/rfc6749#section-2.1"/>

Clients incapable of maintaining the confidentiality of their credentials

Public Clients

<a href="https://tools.ietf.org/html/rfc6749#section-2.1"/>

Public

Confidential

Tokens

Types

  • Reference

  • Self-Contained

identifiers for a token stored on the token service

Reference Tokens

The recipient needs to open a back-channel to the token service

<a href="https://leastprivilege.com/2015/11/25/reference-tokens-and-introspection/"/>

protected, time-limited data structure that contains metadata and claims

Self-Contained Tokens

<a href="https://leastprivilege.com/2015/11/25/reference-tokens-and-introspection/"/>

The recipient of a self-contained token can validate the token locally by checking the signature

Roles

  • Access Tokens

  • Refresh Tokens

  • Id Tokens

OAuth 2.0

OIDC

Access tokens are credentials used to access protected resources

Access Tokens

<a href="https://tools.ietf.org/html/rfc6749#section-1.4"/>

Refresh tokens are credentials used to obtain access tokens.

Refresh Tokens

<a href="https://tools.ietf.org/html/rfc6749#section-1.5"/>

Issuing a refresh token is optional at the discretion of the authorization server.
a security token that contains Claims about the Authentication of an End-User

<a href="https://openid.net/specs/openid-connect-core-1_0.html#IDToken"/>

ID Tokens

Claims

Piece of information asserted about an Entity.

<a href="https://openid.net/specs/openid-connect-core-1_0.html#Terminology"/>

Standard Claims

  • sb (subject identifier)

  • name

  • given_name

  • family_name

  • middle_name

  • nickname

  • preferred_username

  • profile

  • picture

  • website

  • email

  • email_verified

  • gender

  • birthdate

  • zoneinfo

  • locale

  • phone_number

  • phone_number_verified

  • address

  • updated_at

<a href="https://openid.net/specs/openid-connect-core-1_0.html#StandardClaims"/>

Scopes

Scope is a mechanism in OAuth 2.0 to limit an application's access to a user's account
The access token issued to the application will be limited to the scopes grants

<a href="https://oauth.net/2/scope/"/>

Recap

  • Tokens

    • Types

      • Reference

      • Self-Contained

    • Roles

      • Access

      • Refresh

      • ID

  • Claims

    • Pre-Defined

    • Custom

Flows

Authorization Grant

A credential representing the resource owner's authorization used by the client to obtain an access token.

<a href="https://tools.ietf.org/html/rfc6749#section-1.3"/>

  • Implicit

  • Authorization Code

  • Client Credentials

  • Resource Owner Password Credentials

  • Device Authorization Grant

Grant Types

(grant_type)

  • Implicit

  • Authorization Code

  • Hybrid

Flows

(response_type)

Implicit

    
    
    
    
    
     
     
     
     +----------+
     |          |
     |  User-   |
     |  Agent   |
     |          |
     |          |
     |          |
     |          |
     |          |
     |          |
     |          |
     |          |
     |          |
     |          |
     +----------+
       | 
      (A)
       | 
       ^ 
     +---------+
     |         |
     |  Client |
     |         |
     +---------+

<a href="https://tools.ietf.org/html/rfc6749#section-4.2"/>

          Client Identifier     +---------------+
----(A)-- & Redirection URI --->|               |
                                | Authorization |
                                |     Server    |
                                |               |
                                |               |
                                +---------------+
 +----------+
 | Resource |
 |  Owner   |
 |          |
 +----------+
      ^
      |
     (B)
----(B)-- User authenticates -->
<---(C)--- Redirection URI ----<
          with Access Token     
            in Fragment
                                +---------------+
----(D)--- Redirection URI ---->|   Web-Hosted  |
          without Fragment      |     Client    |
                                |    Resource   |
                                |               |
                                +---------------+
<---(E)------- Script ---------<
(F)
 |
(G) Access Token (+ ID Token for OIDC)
 |
 v

<img src="google images"/>

PROS/CONS

  • Users credentials in a trusted Application

  • Tokens in the browser

  • Deprecated in favor of Auth Code

Authorization Code

<a href="https://tools.ietf.org/html/rfc6749#section-4.1"/>

    
    
    
    
    
     
     
     
     +----------+
     |          |
     |  User-   |
     |  Agent   |
     |          |
     |          |
     +----------+
       | 
      (A)
       | 
       ^ 
     +---------+
     |         |
     |  Client |
     |         |
     +---------+
          Client Identifier     +---------------+
----(A)-- & Redirection URI --->|               |
               (+PKCE)          | Authorization |
                                |     Server    |
                                |               |
                                |               |
                                +---------------+
 +----------+
 | Resource |
 |  Owner   |
 |          |
 +----------+
      ^
      |
     (B)
----(B)-- User authenticates -->
---(C)-- Authorization Code ---<
                                      ^ 
                                      | 
                                      | 
                                      | 
                                      | 
>---(D)-- Authorization Code ---------' 
          & Redirection URI (+PKCE*)
 
 | 
(C)
 | 
 v 
                                             v
                                             |
                                             |
                                             |
                                             |
                                             |
                                             |
                                             |
<---(E)----- Access Token (+ ID Token)-------'
       (w/ Optional Refresh Token)

*PKCE is optional but recommended

<img src="google images"/>

PROS/CONS

  • Users Credentials in a trusted Application

  • No tokens in the browser

  • Protections agains code injection and replay attacks with PKCE

Client Credentials

     +---------+
     |         |
     |         |
     | Client  |
     |         |
     |         |
     +---------+

<a href="https://tools.ietf.org/html/rfc6749#section-4.4"/>

                                  +---------------+
                                  |               |
>--(A)- Client Authentication --->| Authorization |
                                  |     Server    |
                                  |               |
                                  |               |
                                  +---------------+
<--(B)---- Access Token ---------<

Resource Owner Password Credentials

<a href="https://tools.ietf.org/html/rfc6749#section-4.3"/>

     +----------+
     | Resource |
     |  Owner   |
     |          |
     +----------+
          v
          |    Resource Owner
         (A) Password Credentials
          |
          v
     +---------+
     |         |
     |         |
     | Client  |
     |         |
     |         |
     +---------+

                                  +---------------+
>--(B)---- Resource Owner ------->|               |
         Password Credentials     | Authorization |
                                  |     Server    |
                                  |               |
                                  |               |
                                  +---------------+
<--(C)---- Access Token ---------<
    (w/ Optional Refresh Token)   
                                  

<img src="google images"/>

PROS/CONS

  • Users credentials in untrusted Applications

  • Tokens in the browser/application

  • Deprecated in favor of Auth Code

Device Authorization Grant

<a href="https://tools.ietf.org/html/rfc8628#section-1"/>

      +----------+                                +----------------+
      |          |>---(A)-- Client Identifier --->|                |
      |          |                                |                |
      |          |                                |                |
      |          |                                |                |
      |  Device  |                                |                |
      |  Client  |                                |                |
      |          |                                |                |
      |          |                                |                |
      |          |                                |                |
      |          |                                |  Authorization |
      |          |                                |     Server     |
      +----------+                                |                |
                                                  |                |
                                                  |                |
                                                  |                |
                                                  |                |
                                                  |                |
                                                  |                |
                                                  |                |
                                                  |                |
                                                  |                |
                                                  +----------------+
<---(B)-- Device Code, --------<
          User Code,            
          & Verification URI    
      v
      : 
     (C) User Code & Verification URI
      :  
      v  
+----------+
| End User |
|    at    |
|  Browser |
+----------+ 
<---(D)-- End user reviews  --->
          authorization request 
  [polling]                     
>---(E)-- Device Code --------->
          & Client Identifier   

<---(F)-- Access Token --------<
   (& Optional Refresh Token)   

<img src="google images"/>

PROS/CONS

  • Authentication on devices without input/browser capabilities

  • More reliable (no credentials inserted)

Hybrid

<a href="https://tools.ietf.org/html/rfc6749#section-4.1"/>

    
    
    
    
    
     
     
     
     +----------+
     |          |
     |  User-   |
     |  Agent   |
     |          |
     |          |
     +----------+
       | 
      (A)
       | 
       ^ 
     +---------+
     |         |
     |  Client |
     |         |
     +---------+
          Client Identifier     +---------------+
----(A)-- & Redirection URI --->|               |
                                | Authorization |
                                |     Server    |
                                |               |
                                |               |
                                +---------------+
 +----------+
 | Resource |
 |  Owner   |
 |          |
 +----------+
      ^
      |
     (B)
----(B)-- User authenticates -->
---(C)-- Authorization Code ---<
           (+ ID Token)

                                      ^ 
                                      | 
                                      | 
                                      | 
                                      | 
>---(D)-- Authorization Code ---------' 
          & Redirection URI             
 | 
(C)
 | 
 v 
                                             v
                                             |
                                             |
                                             |
                                             |
                                             |
                                             |
                                             |
<---(E)----- Access Token (+ ID Token)-------'
       (w/ Optional Refresh Token)

<img src="google images"/>

PROS/CONS

  • Users Credentials in a trusted Application

  • No access tokens in the browser

  • Protections agains code injection and replay attacks with PKCE

  • ID token in the browser, could be leaked

Recap

  • OAuth 2.0

    • Grant Types

  • OIDC
    • Flows

  • Implicit

  • Authorization Code

  • Client Credentials

  • Resource Owner

  • Device Authorization Grant

  • Hybrid

Pitfalls

Weak Credentials

123456

password

qwerty

secret

qazwsx!"#

Hardcoded Secrets

If Request.QueryString("key") = "██████" AndAlso Request.QueryString("key2") = "██████" Then
	unlocked.Visible = True
Else
	unlocked.Visible = False
End IF

Too Permissive Access Control

<a href="https://tools.ietf.org/html/rfc6819#section-3.1.1"/>

Scopes are the OAuth way of explicitly manage the power associated with an access token.

Session Fixation

(Attacker)

(Victim)

(Authorization Server)

(Application A)

<a href="http://web.archive.org/web/20170816002521/https://sakurity.com/oauth"/>

(fixates session)

(attacker's session)

(sends crafted URL to AS)

(users already had account)

(goes to AS and accepts consent)

(attacker's tokens returned)

(sends tokens to application, previous account associated)

(uses account to access victim's account)

Leaked Tokens to Third-Parties

GET /code.js HTTP/1.1
Host: a.third.party
User-Agent: browser-os
Accept: */*
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
Referer: https://mysite.com/reset_password?token=123456789abcdef
Connection: keep-alive

CSRF

(Authorization Server)

(Victim)

(Malicious App)

(API)

(navigates to malicious site)

(tells the browser to perform consent)

(commands AS to accept consent)

(steals victim's info)

<img src="google images"/>

Open-Redirect

(Attacker)

(Authorization Server)

(Victim)

(Application)

(Malicious App)

(maliciouly crafted URL)

(goes to AS and Authenticates)

(AS tells to be redirected to Malicious APP)

(expected landing)

(malicious redirect)

https://identity.provider/login?returnUrl=/connect/authorize/callback?

    client_id=CLIENT

    &redirect_uri=https://url.com/
    &response_mode=form_post
    &response_type=id_token token
    &scope=openid
    &state=OpenIdConnect.AuthenticationProperties=metadata
    &nonce=number_used_once

https://url.com.malicious.domain/

https://url.com*

Replay Attacks

https://identity.provider/login?returnUrl=/connect/authorize/callback?

    client_id=CLIENT

    &redirect_uri=https://url.com/
    &response_mode=form_post
    &response_type=id_token token
    &scope=openid
    &state=metadata
    &nonce=number_used_once

Improper Client Usage

Public

Confidential

client_id

client_secret

client_id

client_secret

Clickjacking

X-Frame-Options

<img src="google images"/>

<img src="google images"/>

Logged Tokens

Bearer tokens should not be passed in page URLs. If bearer tokens are passed in page URLs, attackers might be able to steal them from the browser history data, logs, or other unsecured locations.

<a href="https://tools.ietf.org/html/rfc6750#section-5.3"/>

Improper Token TTL

Token servers should issue short-lived (one hour or less) bearer tokens, particularly when issuing tokens to clients that run within a web browser or other environments where information leakage may occur.

<a href="https://tools.ietf.org/html/rfc6750#section-5.3"/>

Insecure Channels

Clients must always use TLS or equivalent transport security when making requests with bearer tokens.

<a href="https://tools.ietf.org/html/rfc6750#section-5.3"/>

Improper Token usage

If the token leaves the company infrastructure, use reference tokens to be in complete control over lifetime. If the token is used internally only, self-contained tokens are fine.

<a href="https://leastprivilege.com/2015/11/25/reference-tokens-and-introspection/"/>

Scenarios

  • Single Front-End
  • Single Back-End
  • No Federation

Assumptions

(Front-End)

(Back-End)

Conclusions

  • Too Complicated

  • No benefits

  • Multiple Front-End with Back-Ends
  • Multiple APIs
  • May use Federation

Assumptions

(Front-End)

(Back-End)

Conclusions

  • Users' credentials in the same App

  • Keep self-contained tokens in your private infrastructure

  • Use short time to live

  • Multiple Front-Ends
  • No Back-Ends
  • Multiple APIs
  • May use Federation

Assumptions

(SPA)

(Mobile)

Conclusions

  • Go for flows that don't need client credentials

  • Users' credentials in the same App

  • Keep self-contained tokens in your private infrastructure
  • Use short time to live
  • Out of your infrastructure, use reference tokens

?

Thank you

Made with Slides.com