Web Application Security + OAuth2 NWEN 304: Advanced Network Applications

Today What is OAuth How it works How you use it

What is OAuth “An open protocol to allow secure authorization in a simple and standard method from web, mobile and desktop applications.” HTTP based authorisation Primarily designed for authorisation, but is often used for authentication as well You must use it for authentication in project 2 Credit:

Delegate capabilities OAuth lets you delegate capabilities and privileges E.g. if you use add-on software - you want it to access your resources so it can be helpful to you - but you don’t want it to *be* you OAuth allows you to share your private resources (photos, videos, contact list, bank accounts) stored on one site with another site without having to hand out your username and password.

OAuth vs SAML SAMLSAML - a set of standards designed to share info - describe who a user is - describe user’s attributes - Give you a way to grant/deny access to something OAuthOAuth - More about delegating access to something. - You allow someone to “act” as you - Its most commonly used to grant access to api's that can do something on your behalf.

Why use OAuth (service and developer perspective) A third party provides authentication and authorisation => Developers can focus on building their applications rather than building an authentication system Usernames and passwords are not handled by the application => A service provider collects and processes authentication details => The application doesn’t have to worry about storing credentials (plain text problems etc.)

Why use OAuth (user perspective) Centralises management of user accounts => Don’t need to have 1000s of accounts => Fewer passwords to remember

Why use OAuth (user) User’s specify what permissions are granted to each application => You specify whether an app can access your etc. => Fine-grain access control

Why use OAuth (user) Provides dynamic access control mechanism => You can control who has access to what => No need to delete accounts etc., you can just remove an application’s access

Why use OAuth (user) You can change passwords and not effect every account you have OAuth is completely transparent to the users => if done right, they may not even know it is there

History of OAuth OAuth 1.0 released in Twitter developers realised that OpenID was not going to support delegated API access well - OAuth then adopted into IETF: RFC : OAuth 1.0a fixes a session fixation flaw - Can choose not to encrypt Susceptible to authentication failures if client and server don't agree on argument order/signatures etc. Primary focus is web browser Can provide difficulty authenticating non-browser apps Technically deprecated by OAuth 2 Credit:

OAuth2.0 OAuth 2.0 is current evolution [RFC6749,6750] - Supported by Facebook, Twitter, Google, MS, etc … however a committee effort made it complex - Released in 2012 (… intended for 2010 release) - Must use encryption No signatures: No issue with argument ordering Potentially better for larger scale implementations – Authentication and authorization can be provided by different servers – More suitable for corporate authentication Some feel OAuth 2 is not a positive replacement for OAuth 1 – Not backward compatible with OAuth 1 – Leaves many details up to implementer: Can lead to incompatible, yet compliant, implementations

OAuth2.0 Roles There are four key roles (actors) when discussing OAuth flows: - Resource Owner (OR) - Client - Resource Server (RS) - Authorisation Server (AS)

OAuth2.0 Roles Cont. Resource Owner (RO): the end user (you) Grants access to some part of their account Not necessarily a user though… Client: software trying to access RO’s data Websites Apps and games Anything that says ‘sign in with Facebook’ etc. According to Facebook, 81 of the top 100 grossing iOS apps and 62 of the top 100 grossing Android apps use Login with Facebook

OAuth2.0 Roles Cont. Resource Server (RS): Where RO’s data is stored Authorisation Server (AS): Google/Twitter/Facebook etc. Authenticates RO Issues access tokens to client

How to use OAuth2.0 First, you must register your app (the client) with an authorisation server, e.g. google. Registration is a one time thing for the application – there is no mention of ROs etc. When registering your app you specify: - application name - logo etc. - website or host name - return URL (how focus is returned to the application after login)

How to use OAuth2.0 Registering gives you credentials: ClientID (public) Client Secret (private) ClientID identifies the application Clients are either public or confidential: confidential: clients can keep secrets (apps) public: client can’t (JS in a browser) The client secret is only useful to confidential apps

OAuth Authorisation Flow - Client wants access to a resource server. - Starts by presenting the resource owner (user) with a login screen to an AS (Facebook etc.) Detailed: introduction-to-oauth-2

Oauth Authentication Flow

OAuth2.0 Grant Types OAuth provides several grant types. E.g.: - Authorisation Code (e.g. previous slide) - Implicit - RO Password Credentials -Client Credentials These are used in different use cases.

OAuth2.0 Grant Types Authorisation Code – for apps on a web server: The AS is an intermediary between the RO and the Client - RO never shares credential with Client - Client never shares credential with RO Implicit – for browser-based or mobile apps: Skips the auth code step - Token delivered to client - Good for javascript apps etc.

OAuth2.0 Grant Types RO Password Credentials – for getting RO’s credentials - Must trust the client a lot… - Makes sense for client apps developed by the resource server. E.g. the official facebook app. Client Credentials – used with Applications API access

Example Super simple! It is essentially copy-paste and tell it to ‘authenticate()’, then it sorts itself out. There is a lot of info online! An example with Passport: facebook

Passport Example Start by registering an application with facebook. This gives you an appID and app secret. You have to configure a redirect address. > npm install passport-facebook

Example var Strategy = require('passport-facebook').Strategy; … passport.use(new FacebookStrategy({ clientID: FACEBOOK_APP_ID, clientSecret: FACEBOOK_APP_SECRET, callbackURL: " }, function(accessToken, refreshToken, profile, cb) { User.findOrCreate({ facebookId: profile.id }, function (err, user) { return cb(err, user); }); }));

Example Use passport.authenticate(), specifying the 'facebook' strategy, to authenticate requests. app.get('/auth/facebook', passport.authenticate('facebook')); app.get('/auth/facebook/callback', passport.authenticate('facebook', { failureRedirect: '/login' }), function(req, res) { // Successful authentication, redirect home. res.redirect('/'); });

Example: Other Requesting specific permissions (you define scopes): app.get('/auth/facebook', passport.authenticate('facebook', { authType: 'rerequest', scope: ['user_friends', 'manage_pages'] }));