Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Learn Authentication The Hard Way

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.

Andrew Best

April 08, 2020
Tweet

More Decks by Andrew Best

Other Decks in Programming

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