Learn Authentication The Hard Way

If you work with software systems, security is one of your primary concerns. User security is not Someone Else’s Problem. The prevailing advice for building secure systems is to not roll your own security mechanisms.

These two statements are in conflict - should we be responsible for ensuring our systems are secure, or should we delegate security concerns to experts?

In this talk we will dive into the specifications that underpin modern authentication solutions - In particular OpenID Connect and OAuth 2.0. We might also take a sneaky peak at OAuth 2.1!

We won't just read them though - we are doing this the hard way, and will have a go at implementing them!

This talk will build your familiarity with several security specifications, your comfort level of diving into and wrangling them, and allow you to take accountability when selecting and implementing security solutions.

Transcript

1. Learn
   Authentication
   The Hard Way
   Andrew Best
   

   View Slide

2. But Why The Hard Way?
   ▪ We must be responsible for our user’s security – they should be free to use our
   systems free from fear of compromise or consequence.
   ▪ We must not roll our own security mechanisms from scratch
   ▪ If you are an expert, be responsible for security. If you are not an expert, be
   accountable for security.
   ▪ There is no accountability without understanding
   ▪ Understanding security for software developers means understanding
   authentication
   ▪ Modern authentication solutions are built on standards – OAuth 2.0, and OpenID
   Connect
   

   View Slide

3. What it isn’t
   OAUTH
   

   View Slide

4. What it is
   The Plan
   

   View Slide

5. The Plan: Implement Authorization Code Flow
   A.K.A “The Client”
   

   View Slide

6. 8 Steps To Auth Code Flow
   1. Client prepares an Authentication Request.
   2. Client sends the request to the Authorization Server.
   3. Authorization Server Authenticates the End-User.
   4. Authorization Server obtains End-User Consent/Authorization.
   5. Authorization Server sends the End-User back to the Client with an Authorization
   Code.
   6. Client requests a response using the Authorization Code at the Token Endpoint.
   7. Client receives a response that contains an ID Token and Access Token in the
   response body.
   8. Client validates the ID token and retrieves the End-User's Subject Identifier.
   

   View Slide

7. A Tale of Two Endpoints
   

   View Slide

8. Part 1:
   Rabbit Holes
   (The /authorize endpoint)
   

   View Slide

9. The Rabbit Hole
   1. OIDC 3.1.2.1 Authentication Request state parameter CSRF mitigation
   RECOMMENDED
   2. OIDC 3.1.2.7 Authentication Response Validation for code flow, Client MUST
   validate request as per OAuth 2.0 4.1.2 and 10.12
   3. OAuth 2.0 10.12 Client MUST implement CSRF protection for its redirection
   URI, and SHOULD use the state parameter for it, value should be non-
   guessable as per 10.10
   4. OAuth 2.0 10.10 probability of attacker guessing a token SHOULD be less than
   2^(-160)
   5. OWASP CSRF prevention patterns
   

   View Slide

10. 8 Steps To Auth Code Flow
    1. Client prepares an Authentication Request.
    2. Client sends the request to the Authorization Server.
    3. Authorization Server Authenticates the End-User.
    4. Authorization Server obtains End-User Consent/Authorization.
    5. Authorization Server sends the End-User back to the Client with an Authorization
    Code.
    6. Client requests a response using the Authorization Code at the Token Endpoint.
    7. Client receives a response that contains an ID Token and Access Token in the
    response body.
    8. Client validates the ID token and retrieves the End-User's Subject Identifier.
    

    View Slide

11. Part 2:
    Rabbit Warrens
    (The /token endpoint)
    

    View Slide

12. What we are about to explore
    ▪ JWT: How tokens are defined
    ▪ JWS: How tokens are secured
    ▪ JWE: How to determine whether a
    JWT is a JWS or a JWE
    ▪ JWA: Algorithms for securing tokens
    ▪ JWKS: How to provide crypto keys
    ▪ PKCS #1: RSA cryptography
    OIDC 3.1.3.7:
    ID Token Validation
    RFC 7519
    RFC 7515
    RFC 7518
    RFC 3447
    RFC 7517
    RFC 7516
    

    View Slide

13. 8 Steps To Auth Code Flow
    1. Client prepares an Authentication Request.
    2. Client sends the request to the Authorization Server.
    3. Authorization Server Authenticates the End-User.
    4. Authorization Server obtains End-User Consent/Authorization.
    5. Authorization Server sends the End-User back to the Client with an Authorization
    Code.
    6. Client requests a response using the Authorization Code at the Token Endpoint.
    7. Client receives a response that contains an ID Token and Access Token in the
    response body.
    8. Client validates the ID token and retrieves the End-User's Subject Identifier.
    

    View Slide

14. Part 3:
    The Future
    (OAuth 2.1)
    

    View Slide

15. What Lies Ahead
    Now Future
    Credit: Aaron Parecki
    https://aaronparecki.com/2019/12/12/21/its-time-for-oauth-2-
    dot-1
    

    View Slide

16. Why OAuth 2.1?
    • People will be able to know
    where to start when learning
    about the topic
    • Reduce the fragmentation
    across the specifications
    • Gets rid of deprecated and
    insecure specifications
    

    View Slide

17. What About 3?
    https://oauth.xyz/
    

    View Slide

18. Thanks!
    @_andrewb
    andrew-best.com
    github.com/andrewabest
    speakerdeck.com/andrewabest
    

    View Slide