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
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
3. What it isn’t OAUTH
4. What it is The Plan
5. The Plan: Implement Authorization Code Flow A.K.A “The Client”
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.
7. A Tale of Two Endpoints
8. Part 1: Rabbit Holes (The /authorize endpoint)
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
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.
11. Part 2: Rabbit Warrens (The /token endpoint)
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
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.
14. Part 3: The Future (OAuth 2.1)
15. What Lies Ahead Now Future Credit: Aaron Parecki https://aaronparecki.com/2019/12/12/21/its-time-for-oauth-2- dot-1
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
17. What About 3? https://oauth.xyz/
18. Thanks! @_andrewb andrew-best.com github.com/andrewabest speakerdeck.com/andrewabest