Y U No OAuth, Using Common Patterns to Secure Your Web Applications

Y U NO OAUTH?!? Using Common Patterns to Secure Your Web Applications Jason Robert Twitter – @jasontrobert Website – espressocoder.com Linkedin – in/jasonrobert/

Meet the Speaker ■ Software Architect ■ Bootcamp Instructor ■ Blogger & Speaker ■ Blogs @ https://espressocoder.com ■ PASSIONATE DEVELOPER & MENTOR

Roadmap ■ Progression of User Management in the Web ■ JWTs, OAuth 2.0, and OpenID Connect ■ Authentication Methods ■ Choosing an Identity Provider

PROGRESSION OF USER MANAGEMENT IN THE WEB

“Roll Your Own” ■ You’re responsible for all aspects of identity management – User management, storage, and authentication ■ Users need to be created, administered, and managed ■ Users and passwords in a persistent store – Please tell me you hashed and salted those passwords! ■ Session can be managed via session state and/or cookie

ASP.NET Identity ■ Introduced in ASP.NET 2.0 – aspnet_regsql.exe – ASPNET Web Administration Tool ■ Designed to solve site membership requirements that were common at the time ■ Forms-based Authentication (user-name / password) ■ Database backend for user names, passwords, and profile data – Profile data requires the Profile Provider API

Modern ASP.NET Identity ■ ASP.NET Identity works with claims-based authentication – Identity is represented as a set of claims ■ Supports redirection-based login with authentication providers – Google, Facebook, Twitter, etc. ■ Storage based on EF Core and extensible ■ Distributed as a NuGet package(s) – Microsoft.AspNetCore.EntityFramework.Identity

Distributed Web Architectures ■ But what about… – Dealing with multiple web applications – Native or legacy systems – Server to server communication – 3rd party integration – Single sign-on ■ ASP.NET Identity isn’t always ideal for distributed architectures like Microservices ■ Is there another way?

USE AN OAUTH 2.0 IDENTITY PROVIDER

What is an Identity Provider? ■ Creates, maintains, and manages information for principals while providing authentication services to relying applications ■ Provides centralized login and workflow for all of your applications – Web, native, mobile, etc. ■ Hosted as a separate web application (Separation of Concerns) ■ Enables Single Sign-on – User friendly – Reduces attack surface

JSON Web Tokens (JWTs) ■ Compact and self-contained way to securely transmit information between two applications ■ Contains claims about a principal enabling authorization rules to be enforced ■ A JWT is digitally signed to verify authenticity ■ Typically Base64 encoded but can be encrypted via JSON Web Encryption (JWE)

Structure of a JWT ■ Header – Contains two key pieces of information ■ The type of the token (JWT) ■ The signing algorithm ■ Payload – Contains the claims ■ Claims are statements about an entity / user ■ Signature – Contains a signature of the Header & Payload ■ Typically uses a strong encryption algorithm

Access Token vs Id Token ■ ID Token – Shows client application that user authenticated successfully – Contains information (claims) about a principle – Authentication response ■ Access Token – Provides “access” to a secure resource – Typically used as a bearer token – Should be managed securely

OAuth 2.0 ■ Industry-standard protocol for authorization ■ Provides specific authorization processes for web, desktop, and mobile applications ■ Describes several “grant types” for acquiring an access token – Client Credentials – Password – Authorization Code – Implicit

OpenID Connect ■ OpenID Connect is an authentication protocol based on the OAuth 2.0 specifications ■ OpenID Connect lets developers authenticate their users across websites and apps ■ Presents three flows for authentication that dictate how authentication is handled by the Identity Provider – Authorization Code Flow – Implicit Flow – Hybrid Flow

WHAT TYPES OF APPLICATIONS DO YOU WORK WITH?

Client Credentials ■ Obtain a token outside the context of a user ■ Use to when communicating across two backend systems ■ Authentication is performed via client_id & client_secret ■ Think of Client ID & Client Secret as UserName and Password Client ID / Client Secret may be required as a Basic Auth header or included in the post body The grant_type is client_credentials

Client Credentials Client ID / Client Secret used for authentication JWT Access Token issued Token provided as a “bearer” authorization http header 1 2 3

Client Credentials Expiration When the token expires Audience Who the token is for Issuer Where the token came from

Client ID and Client Secret provided in authentication header The grant_type must be set to client_credentials

The token is provided in an authorization header as a Bearer token

Authority must match the “iss” claim Audience must match the “aud” claim

Password ■ Similar to client credentials but, with a user’s context ■ Use with native or legacy applications – Never use with your web apps! ■ Requires user name and password – In addition to client_id and client_secret Username and password fields are introduced The grant_type is password

Password Client ID, Client Secret, UserName, and Password used for authentication JWT Access Token issued Token provided as a “bearer” authorization http header 1 2 3

Password Authentication Method Reference How the principle authenticated Password-based Authentication Subject Unique Id for the principle

Username and password are now included in the request Client ID and Client Secret provided in authentication header

The password token is provided to the api in the exact same way as before

Authorization Policies can be used for routes that require a “sub” claim Authentication is setup in the same way

Policies can be assigned to controllers for authorization

Implicit Flow ■ The browser requests a token directly from the authorization server ■ The authorization server redirects to the redirect_uri with the id_token ■ Can be used with server-side web applications such as ASP.NET Core MVC ■ Do not use with Single Page Applications! Token is returned via redirect

Implicit Flow User browses to web application 1 2 3 4 Redirects to the identity provider User authenticates with identity provider Identity provider redirects back to web application with id_token

Implicit Flow Nonce used to prevent replay attacks. Must match the nonce provided by initial redirect request Unique Session ID

ASP.NET Core Middleware can be used to facilitate OpenIdConnect Implicit Flow After the id_token is received a session is established with the web application

SERVER SIDE WEB APPLICATIONS WITH API

Hybrid Flow 1 2 ■ Uses redirect uri to return id_token AND code ■ Use with server-side web applications that additionally need to call a backend api ■ Code is used server-side in order to retrieve an access_token ■ Authorization code’s can only be used once

Hybrid Flow 1 User gets redirected to Identity Provider 2 3 4 User authenticates and receives code and id_token Authorization code is used to retrieve access_token (and new code) Access_token is used to authenticate with secure api

ASP.NET Core Middleware can be used to facilitate OpenIdConnect Implicit Flow ASP.NET Core Middleware can be used to facilitate OpenIdConnect Implicit Flow

Why Implicit Flow is bad for SPAs ■ SPA applications need an access_token ■ Response types causing the authorization server to issue access tokens in the authorization response are vulnerable to access token leakage ■ Don’t panic if you are using implicit flow but, recognize better options are now available

Authorization Code with PKCE ■ New recommendation for SPAs ■ Redirect from authorization server only contains an authorization code – Protected by PKCE ■ PKCE mitigates the threat of having the authorization code intercepted ■ Browser requests token with authorization code 1 2

Authorization Code with PKCE 1 2 Redirects to the identity provider Redirects to authorization server with code_challenge After successful authentication, authorization code is returned to redirect url 3 Authorization code is provided with code_verifier. Upon successful validation, id_token, access_token are returned

Weighing Your Options ■ Choose an Identity Provider that fits with your ecosystem – Is your solution an internal application? – Is your solution cloud hosted? – Which cloud provider do you use? – What level of control is required? ■ Validate it is OpenID Connect Certified!

On-Premise… Active Directory Federation Services 2016

Still not sure? https://openid.net/certification/

Graduated! You’ve learned… ■ Progression of User Management in the Web ■ JWTs, OAuth 2.0, and OpenID Connect ■ Authentication Methods ■ Choosing an Identity Provider

Jason Robert Twitter - @jasontrobert Website – espressocoder.com Linkedin - in/jasonrobert/

Y U No OAuth, Using Common Patterns to Secure Your Web Applications

Y U No OAuth, Using Common Patterns to Secure Your Web Applications

More Related Content

What's hot

Similar to Y U No OAuth, Using Common Patterns to Secure Your Web Applications

Recently uploaded

Y U No OAuth, Using Common Patterns to Secure Your Web Applications

Editor's Notes