OAuth - Balint Erdi and Philippe de Ryck

SECURE AUTHENTICATION
WITH OAUTH 2.0 IN

Balint Erdi - Philippe De Ryck
Emberconf 2017
@baaz @PhilippeDeRyck
https://balinterdi.com/
@baaz / @PhilippeDeRyck https://www.websec.be
WHO HERE FULLY UNDERSTANDS OAUTH 2.0?
@baaz / @PhilippeDeRyck
OAUTH 2.0 IS A MESS
ABOUT US – BALINT ERDI
§ Balint is a total Ember enthusiast
− Regularly consults with large companies on building Ember apps
− Numerous screencasts and blog posts about Ember concepts
− Organizes workshops on various Ember topics, including authentication
− Gives another talk here at EmberConf!
− More info on https://balinterdi.com/
§ Author of the popular book Rock and Roll with Ember.js

− Kept up-to-date with the latest evolutions in Ember
− Pinpoints the core concepts and explains them in detail
ABOUT US – PHILIPPE DE RYCK
§ My goal is to help you build secure web applications
− Hosted and customized in-house training
− Specialized security assessments of critical systems
− Threat landscape analysis and prioritization of security efforts
− More information and resources on https://www.websec.be
§ My security expertise is broad, with a focus on Web Security

− PhD in client-side web security
− Main author of the Primer on client-side web security
@baaz / @PhilippeDeRyck 5
WE WILL FOCUS ON AUTHENTICATION WITH OAUTH 2.0
§ OAuth 2.0 is a very versatile framework, used for various purposes
− In this workshop, we explicitly limit the scope to authentication
− The advice given here therefore applies to authentication scenarios
§ In the coming hours, we will dive deep into OAuth 2.0

− A couple of lectures explain important concepts and security properties
− The hands-on lab sessions put you in the driver’s seat
§ If you have any questions, don’t wait to ask them!

− During the lab sessions, there should be some time for broader questions as well
WHAT YOU WILL LEARN IN THIS WORKSHOP
§ In-depth understanding of the subtleties of OAuth 2.0
− The difference between the four main OAuth 2.0 flows
− Practical advice which flow you should be using, and why
− The relation of OpenID Connect with OAuth 2.0 and authentication
§ Hands-on experience with implementing OAuth 2.0 authentication in Ember

− Using a combination of Ember-Simple-Auth and Torii
− A look under the hood of a Torii provider
§ Detailed overview of common threats against OAuth 2.0 flows

− Hands-on experience with investigating the steps in an OAuth 2.0 flow
− Practical attack scenarios and important countermeasures
OAUTH 2.0 AND AUTHENTICATION
WHAT IS OAUTH 2.0 ALL ABOUT?
Delegation
WHAT DELEGATION IS ALL ABOUT …
account X
5 Show me the balance of
$ 50 6
account X
I want to access I want to access

1 account X 3 account X
Sure, here’s my accountant Sure, here’s an

CTO 2 4 bank
permission access card
A PRACTICAL EXAMPLE OF DELEGATION
SO WE CAN USE THIS FOR AUTHENTICATION?
No
BUT AUTHENTICATION WITH OAUTH 2.0 SEEMS SIMPLE …
1 I want to login with Facebook
4 Welcome “PhilDR”
Rock & Roll
User info 3
2 Who is this guy?
user philippe.deryck@cs.kuleuven.be
Facebook
WHY AUTHENTICATION WITH OAUTH 2.0 IS NOT SIMPLE
§ Authenticating a user is about getting verifiable user information
− But we need to know who we are getting that information for
− The authentication provider probably does not just share anybody’s information
§ Remember that OAuth 2.0 is all about delegation

− The user can delegate access to his information to our application
− We can use that access to fetch user information, and authenticate the user
§ What makes OAuth 2.0 (and authentication) complex is this delegation

− We’re using the entire OAuth 2.0 framework to only delegate a tiny bit of access
− And because we only need a bit, we will also be able to simplify things a bit
IN PRACTICE, IT’S A BIT MORE COMPLICATED …
1 I want to login with Facebook
2 Give me access to your FB user info
5 Here’s a token to get my info

Rock & Roll
8 Welcome “PhilDR”
User info 7
6 Show me the user info
user philippe.deryck@cs.kuleuven.be
4 OK, here’s a token that grants access
3 I want to give R&R access to my FB user info Facebook

MAKING SENSE OF OAUTH 2.0 FLOWS
§ The OAuth 2.0 spec offers 4 distinct flows, each with their own purpose
− Choosing the right flow is hard
− Terminology can also be fairly confusing
§ Putting OAuth 2.0 roles in context for authentication

− Client: the Rock & Roll application
− User agent: the browser
− Resource owner: the user that owns the account
− Resource server: the server hosting the account information (e.g. Facebook)
− Authorization server: the server that authenticates the client (e.g. Facebook)
FLOW 1: RESOURCE OWNER PASSWORD CREDENTIALS
User Agent
(resource owner)
6
1 Login with FB Hello “PhilDR”
user: philippe
pass: qwerty12345
I want to access the I want access as user

4 2 philippe with pass …
user info
5 User info 3 OK, here’s a token that

Resource philippe.deryck@cs.kuleuven.be Client grants access Authorization
server Server
FLOW 2: IMPLICIT GRANT
5 Credentials for FB
3 I want to give R&R access
User Agent 4 Please login

(resource owner) 6 OK, here’s a token
1 Login with FB
7 Here’s the FB token
2 OK, go to FB please
10 Hello “PhilDR”
I want to access the
8 user info
9 User info
Resource philippe.deryck@cs.kuleuven.be Client Authorization
server Server
FLOW 3: AUTHORIZATION CODE

(resource owner) 6 OK, here’s an authorization
1 Login with FB code
7 Here’s the code
10
user info Can I have an access
8 token please?
11 User info
Resource philippe.deryck@cs.kuleuven.be Client 9 Here you go Authorization
server Server
FLOW 4: CLIENT CREDENTIALS
3 Access API 1 I want access as myself
4 info 2 OK, here’s a token for that

Resource Client Authorization
server Server
MAKING SENSE OF OAUTH 2.0 FLOWS
§ Resource owner password credentials
− Only relevant if the client and the resource owner trust each other 100%
• E.g. when Facebook builds a Facebook client
§ Implicit Grant
− Directly exposes the access token to the frontend application
• Mainly useful for direct API access from within JavaScript
§ Authorization code
− Preferred flow to ensure the security of the access token
• The flow to use for when the backend needs to access an API
§ Client credentials
− Useful for when the application needs access to an API
WHICH FLOW CAN WE USE TO SUPPORT AUTHENTICATION?
§ There is a lot of conflicting advice out there

− Many applications use the resource owner password credentials flow
− Most tutorials recommend the use of the implicit grant flow
§ In this case, the only right answer is the authorization code flow
− This flow offers the strongest security benefits
− It looks more complex than the implicit grant flow, but in practice it is not
§ This workshop will focus on the implicit grant and authorization code flow
− We will show you the differences and security benefits
− The lab sessions cover both implementation and security aspects
SUPPORTING OAUTH 2.0 IN EMBER
AUTHENTICATION IN EMBER
§ Ember Simple Auth (ESA) is a popular authentication library for Ember
− It offers abstractions for authentication and authorization
− It offers session management features to keep track of authentication state
§ To support different authentication strategies, authenticators are used

− The authentication process is delegated to the specified authenticator
§ To support authorization, various mixins are provided

− Add an authorization check to routes
− Add a session token to outgoing requests
−…
EMBER SIMPLE AUTH CODE EXAMPLE
RUNNING OAUTH 2.0 FLOWS WITH TORII
§ Torii is another popular Ember library to integrate authentication
− It mainly focuses on complex OAuth 2.0 flows
− But also offers support for authorization and session management
§ Torii makes powerful abstractions from complex flows

− An OAuth 2.0 provider runs the entire flow in a popup, and simply returns the results
− All the complex configuration is hidden in the provider
§ Torii already supports numerous OAuth 2.0 flows out of the box
− Support for Google, Facebook, Github, …
− Support for both implicit grant and authorization code flows
TORII CODE EXAMPLE
INTEGRATING TORII WITH EMBER SIMPLE AUTH
§ The power of Torii is that it easily integrates with existing applications
− Existing authentication mechanisms can easily call a Torii provider
§ Custom ESA authenticators delegate the flow to a Torii provider

− Torii takes care of running the OAuth 2.0 flow
− ESA takes care of storing the authentication information after a successful flow
− This integrates directly with the already existing authorization mixins
§ This is exactly what you will do in this workshop
BACKEND SUPPORT FOR TORII AND ESA
§ The backend is responsible for processing the OAuth 2.0 results
− This can either be an access token or authorization code
− With this information, the backend fetches associated identity information
§ Contacting the backend can easily be done from within the authenticator
− After the OAuth 2.0 flow has completed, the result is sent to the server with AJAX
− The server returns a session token after a successful authentication
− This is the token that ESA stores in localStorage
§ For this workshop, we have already implemented the backend endpoints
AUTHENTICATION WITH OAUTH 2.0
Lab session
PRACTICAL INFO FOR THE LAB SESSIONS
§ You will be working on the frontend of the Rock & Roll application
− You should have cloned the repo by now
• If not, check your email for instructions, or call one of the us in a minute
− We will add authentication with OAuth 2.0 by using Google, Facebook and Github
§ All of the lab sessions are fully documented

− The guides that tell you what you need to do, with detailed instructions if necessary
− The repository has branches for each step, so you can always start with a clean slate
§ The backend is running on Heroku, and is shared for everyone

− The relevant source code is included in the guides as code snippets
Guides for the lab sessions

http://bit.ly/2nEAdRj
Slides
http://bit.ly/2n9NzC5
Slack Channel
https://balinterdi.slack.com/, #emberconf17-workshop
WHAT YOU SHOULD TAKE AWAY FROM THIS LAB SESSION
§ Torii and ESA provide a clean set of abstractions for authentication
− Ties in real nice with existing concepts in your Ember application
− Do separate your session management from the OAuth 2.0 authentication
§ OAuth 2.0 can effectively be used for authentication

− Both the implicit grant and authorization code flows are well supported
− Thanks to Torii, frontend implementation is really limited for both flows
§ The backend also plays an important role in the authentication process

− We have shielded you from the backend, but will take a look at it now
SECURITY IN OAUTH 2.0
OAUTH 2.0 FLOWS ARE ALL ABOUT ACCESS TOKENS
§ In every flow, the client gets an access token to access protected resources
− The access token is a bearer token, so whoever possesses it can use it
§ For authentication, the access token is only needed once

− With the access token, the client can fetch user identity information
− With this information, a new session for the user can be established
− After that, the access token should be discarded, as access is no longer needed
§ During the flows, the access tokens need to be adequately protected as well
− All traffic should happen over a secure HTTPS channel
− Exposure of the access token should be limited
− The integrity of the OAuth 2.0 flow should be ensured
NETWORK ATTACKS ARE EASIER THAN EVER TO EXECUTE
ACCESS TOKENS TRAVEL ACROSS THE NETWORK

1 Login with FB
8 user info
9 User info
server Server
LIMITING THE EXPOSURE OF THE ACCESS TOKEN IS CRUCIAL
ACCESS TOKENS TRAVEL THROUGHOUT THE APPLICATION

1 Login with FB
8 user info
9 User info
server Server
ACCESS TOKENS TRAVEL THROUGHOUT THE APPLICATION

7 Here’s the code
10
8 token please?
11 User info
server Server
LIMITING THE EXPOSURE OF THE ACCESS TOKEN IN THE BACKEND
§ Many backend systems need continuous access to the protected resource

− This requires possession of the access token
− But if these tokens get stolen, the user’s are in serious trouble
§ For authentication purposes, the access token can be discarded after use
− At that point, the backend has fetched the user’s identity information
− Discarding the token limits the risk of theft in a data breach
§ The risk of theft is even greater with refresh tokens

− These tokens are long lived and allow a client to get a new access token
− We don’t need those at all, so if you get them, discard them immediately
THE HIDDEN PARTS OF SETTING UP OAUTH 2.0
§ The resource owner needs to grant the client access to the resources
− This requires the registration of a client application with the resource provider
− You need to provide client information, including specific redirect URIs
− During registration, you get a client ID and a client secret
THE HIDDEN PARTS OF SETTING UP OAUTH 2.0
§ The resource owner needs to grant the client access to the resources
− This requires the registration of a client application with the resource provider
− You need to provide client information, including specific redirect URIs
− During registration, you get a client ID and a client secret
§ The client ID is used to identify the client

− This is non-sensitive information and does not need to be kept secret
§ The client secret is used to authenticate the client

− This is essentially a password, and should be kept confidential
− It can be used in the backend, but should never be shared with the frontend
IDENTIFYING THE CLIENT IN THE IMPLICIT GRANT FLOW

1 Login with FB
2
Redirect the browser to Facebook with the client ID
8 user info
9 User info
server Server
THE IMPORTANCE OF PROPER CLIENT IDENTIFICATION
§ Client identification in the implicit grant flow is difficult
− The flow runs entirely in the browser, which is considered to be untrusted
− The client secret cannot be shared with the browser
§ Most implicit grant flows easily accept fraudulent tokens

− Happens when application happily accepts tokens that are issued for application A
11 9 User info
8 Access API
User Agent Bad client Resource
(attacker) server
1 Login with FB
7 FB token 10 Hello “PhilDR”
12 Token 2 Go to FB
Hello
15
“PhilDR” OK, here’s a token
6
13 Access API
4 Please login
3 Authorize bad client

14 User info
Resource Good client User Agent 5 Credentials for FB Authorization
server (resource owner) Server

− To avoid this, the client must explicitly validate the token before use

− To avoid this, the client must explicitly validate the token before use
§ A similar problem exists if the redirect URI can be tampered with

− This will cause the token to be sent directly to the attacker, allowing reuse
REDIRECT URIS HELP ENSURE THE INTEGRITY OF A FLOW
The redirect URI will be 3 I want to give R&R access
propagated along steps 3,
4 and 5 User Agent 4 Please login
1 Login with FB
2
8 user info
Redirect the browser to Facebook, and include
the URI to redirect to in step 6
9 User info
Resource philippe.deryck@cs.kuleuven.be Client
https://accounts.google.com/o/oauth2/auth?client_id=…&redirect Authorization
_uri=http%3A%2F%2Flocalhost%3A4200%2Foauth2callback
server Server
§ A malicious redirect can result in leaking the access token
− To prevent this, the authorization server needs to verify the validity of the URI
− That’s also why you need to specify the redirect URI up front
§ A malicious redirect can result in leaking the access token
− To prevent this, the authorization server needs to verify the validity of the URI
− That’s also why you need to specify the redirect URI up front
§ Open redirects can be abused to steal tokens as well

− An open redirect is a URI within your domain that will trigger a controllable redirect
− This will enable the stealing of the access token
http://example.com/login?src=http://www.example.com/secretCats
§ Make sure your backend does not have a redirect with a controllable URI
WHY THE AUTHORIZATION CODE FLOW IS BETTER
§ By now, you probably realize that the implicit grant flow is not very secure
− There is no client authentication, only identification with a public identifier
− It requires additional effort to ensure the validity of the tokens
− Tokens pass through the browser, making them more vulnerable to exposure
§ The authorization code flow handles these problems a lot better

− Access tokens are never seen by the browser
− Client authentication is done by the authorization server using client ID and secret
§ Even if an authorization code is stolen, the impact is limited to none

− Exchanging a stolen authorization code for an access token requires the client secret
− Authorization codes are one-time use only
IDENTIFYING THE CLIENT IN THE AUTHORIZATION CODE FLOW
2 5 Credentials for FB
Redirect the browser to Facebook with the client ID
8 User Agent 4 Please login

Exchange the authorization code for an access
token using client ID and client secret
7 Here’s the code
10
8 token please?
11 User info
server Server
THE HIDDEN PARTS OF USING AN OAUTH 2.0 FLOW
§ An OAuth 2.0 flow starts with a redirect to the authorization server
− This first request contains parameters to set the properties of the flow
− We already covered the client ID and redirect URI, but there are more
§ Common parameters to configure the flow

− Response type: what the response should include (code or token)
− Scope: the permissions the client is requesting from the resource owner
− State: a random, unique string to protect against Cross-Site Request Forgery
§ These parameters have been hidden so far, because Torii took care of this
− This becomes extremely relevant if you have to write your own provider some day
SCOPE AND PERMISSIONS
SCOPE AND PERMISSIONS
§ The scope parameter allows the client to request specific permissions
− These permissions are shown to the user during authorization of the application
− The list of available permissions is specific to each provider
§ These permissions are associated with the access token

− Access tokens are bearer tokens, so they can be re-used when stolen
− Do not overreach on the scope, and limit the scope to the access you need
− For authentication purposes, access to the email address is generally sufficient
§ Note that the granted permissions can differ from the requested permissions
− Check the granted permissions to see if you have all you need
VIOLATING FLOW INTEGRITY THROUGH CSRF
§ Cross-Site Request Forgery allows an attacker to disrupt the OAuth 2.0 flow
− The attack is to stop the flow in one browser and resuming it in the other browser
− This results in the successful authentication as a different user
User Agent Authorization

(resource owner) Server
4 Please login 5 Credentials
7 Here’s the FB token 6 Token 3 Authorizate R&R
10 Hello “Balint”
8 user info 1 Login with FB
9 User info 2 OK, go to FB please

Resource balinterdi@gmail.com Client User Agent
server (attacker)
§ Cross-Site Request Forgery allows an attacker to disrupt the OAuth 2.0 flow
− The attack is to stop the flow in one browser and resuming it in the other browser
− This results in the successful authentication as a different user
§ The consequence of this attack is very subtle

− All actions the user performs will be done in the name of the attacker
− E.g. if the application stores sensitive user data, such as search queries
− E.g. if the attacker put malicious code in his account, it will be executed by the user
§ The root cause is the separation between initialization and finalization

− The solution is to tie both steps together with the state parameter
LINKING INITIALIZATION AND FINALIZATION WITH STATE
2 5 Credentials for FB
The client includes a random 3 I want to give R&R access
state parameter in the URI
1 Login with FB
8 user info State parameter is propagated
through steps 3, 4, 5, 6 and 7
9 7User info
Resource Client Authorization
Client compares state parameter with the stored value
philippe.deryck@cs.kuleuven.be
server Server
7
State in step 7 does not
match any stored state
User Agent Authorization
(resource owner) Server
4 Please login 5 Credentials
7 Here’s the FB token 6 Token 3 Authorizate R&R
10 Hello “Balint”
8 user info 1 Login with FB
9 User info 2 OK, go to FB please

Resource balinterdi@gmail.com Client User Agent
server (attacker)
RECAPPING SECURITY BEST PRACTICES
§ Limit the exposure of the access token
− Run all traffic over a secure HTTPS channel
− Choose the authorization code flow over the implicit grant flow
− Remove the access token after use
§ Limit the scope of the access token
§ Ensure the integrity of an OAuth 2.0 flow

− Specify concrete redirect URIs and void the presence of open redirects
− Verify the validity of access tokens coming from the client
− Use the state parameter to prevent CSRF attacks (included in Torii’s default providers)
SECURING OAUTH 2.0 FLOWS
Lab session
§ For this lab session, we need a working implementation of OAuth 2.0 flows
− You can continue on your own implementation
− Alternatively, you can check out the facebook-authentication-code branch
§ We are going to investigate the security properties of the different flows

− See what you can do with an access token and authorization code
− We are going to use Burp and Firefox for most of this
− If you run into problems, don’t hesitate to call us over!
§ We can use the same shared backend running on Heroku

− The relevant source code is included in the guides as code snippets
Guides for the lab sessions
http://bit.ly/2nEAdRj
Slides
http://bit.ly/2n9NzC5
Token Inspector
http://bit.ly/2nsybU7
Slack team and channel

https://balinterdi.slack.com/, #emberconf17-workshop
WHAT YOU SHOULD TAKE AWAY FROM THIS LAB SESSION
§ The implicit grant flow is inherently insecure, but often used
− The main reason people advise this flow is because of ease-of-use
− But we have seen that if you do it right, the required effort is very similar
§ Secure OAuth 2.0 flows are all about the details

− Subtle differences between the implicit grant and authorization code flow
− Setting the scope, redirect URI and state parameters requires knowledge
§ Limiting the exposure of the access token is absolutely crucial

− Do not send it via the browser
− Delete it from the backend after authentication
OAUTH 2.0 AND OPENID CONNECT
AUTHENTICATION WITH OAUTH 2.0 IS MESSY
§ Fetching user information with OAuth 2.0 highly depends on the provider
− Every provider has different endpoints for all kinds of data
− Some providers have custom settings (e.g. the email address on Github)
§ Supporting multiple providers is not really easy

− Requires a lot of maintenance, especially when APIs evolve
§ Things become even worse when you need to rely on third party services
− In this workshop, we had our own independent session management
− This is not always the case, and propagating that info across the backend is difficult
OPENID CONNECT TO THE RESCUE
§ OpenID Connect (OIDC) aims to solve these issues
− A standardized way to exchange identity information between services
− Heavily based on JSON Web Tokens (JWT)
§ OIDC is actually built on top of OAuth 2.0

− OAuth 2.0 is a very flexible and open framework
− OIDC makes very explicit choices, and locks OAuth 2.0 down into a specific scenario
§ OIDC still uses the OAuth 2.0 flows we covered here today
− First, the client uses an authorization code flow to get an authorization code
− Next, the authorization code is exchanged for an identity token
FLOW 3: AUTHORIZATION CODE

7 Here’s the code
10
8 token please?
11 User info
server Server
OPENID CONNECT WITH THE AUTHORIZATION CODE FLOW
5 Credentials for Google

1 Login with Google code
7 Here’s the code
2 Go to Google
Id token and access

8 token please?
Client 9 Here you go Token

endpoint
OPENID CONNECT RETURNS AN IDENTITY TOKEN
@baaz / @PhilippeDeRyck http://jwt.io/ 74
A JWT IS A BASE64-ENCODED DATA OBJECT
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJkaXN0cmluZXQuY3Mua3VsZXV2
ZW4uYmUiLCJleHAiOjI0MjUwNzgwMDAwMDAsIm5hbWUiOiJwaGlsaXBwZSIsImFkbWluIjp0c
nVlfQ.dIi1OguZ7K3ADFnPOsmX2nEpF2Asq89g7GTuyQuN3so
{
HMACSHA256(
"iss": ”distrinet.cs
{ base64UrlEncode(header)
.kuleuven.be",
"alg": "HS256", + "." +
"exp": 1425078000000,
"typ": "JWT" base64UrlEncode(payload),
"name": "philippe",
} “secret”
"admin": true
)
}
Header Payload Signature

JWT IS AN OPEN STANDARD TO EXCHANGE INFORMATION
§ JWT tokens represent easy-to-exchange data objects
− Content is signed to ensure integrity
− Content is base64-encoded, to ensure safe handling across the web
§ JWT supports various kinds of algorithms

− E.g. signature with one shared key on the server-side, for use within one application
− E.g. signature with a public/private key pair, for use across applications
§ This makes JWT tokens so useful in an OIDC environment

− Identity information is encoded as a JWT token, signed with a private key
− Any party relying on this info can verify the signature before using the claims

code
1 Login with Google 2 Go to Google

7 Here’s the code 10 Hello “PhilDR”
Id token and access

11 Moar user info 8 token please?
UserInfo 12 Claims about the user Client 9 Here you go Authorization

endpoint Server
ADDITIONAL CLAIMS ARE ALSO REPRESENTED AS A JWT
THE DETAILS BEHIND AN OPENID CONNECT FLOW
§ The scope of the OAuth 2.0 flow should be openid
− This tells the provider that the goal is to get an identity token
− Additional scopes can be added alongside openid (e.g. email, …)
2
Scope should be openid
but can also include others User Agent 4 Please login
(e.g. openid email) (resource owner) 6 OK, here’s an authorization
code
1 Login with Google 2 Go to Google

7 Here’s the code 10 Hello “PhilDR”
Id token and access

11 Moar user info 8 token please?
UserInfo 12 Claims about the user Client 9 Here you go Authorization

endpoint Server
THE DETAILS BEHIND AN OPENID CONNECT FLOW
§ The scope of the OAuth 2.0 flow should be openid
− This tells the provider that the goal is to get an identity token
− Additional scopes can be added alongside openid (e.g. email, …)
§ The endpoints in an OIDC flow are fixed

− The /token endpoint exchanges an authorization code for an identity + access token
− The /UserInfo endpoint requires an access token and gives claims about the user
§ Claims returned by an OIDC service use the JSON Web Token (JWT) format
− A standardized JSON format which supports integrity validation through signatures
SUPPORTING OPENID CONNECT IN TORII
§ By default, Torii does not come with providers for OIDC
− Only OAuth 2.0 implicit grant and authorization code flows are supported
− However, implementing support can be done with a custom provider
§ An OIDC provider in Torii needs to perform the following steps

− Run the authorization code flow with the openid scope
− Configure the correct provider and endpoint to launch that flow
§ The backend will take care of all the other steps

− Exchanging the authorization code for an identity token
− Requesting additional user information from the /UserInfo endpoint
WRAPPING THINGS UP
AUTHENTICATION WITH OAUTH 2.0
§ We have covered how to use OAuth 2.0 flows for authentication
− There is a lot more to OAuth 2.0, that we have not covered
− When you need to continuously access APIs, things become even more tricky
§ Specifically for authentication, take the following into account

− Do not use the implicit grant flow unless there is absolutely no way around it
− Make sure the backend implements proper checks (e.g. token validity, …)
§ Always remember that OAuth 2.0 is a delegation protocol

− It does not perform authentication or authorization, that’s all up to you
IMPLEMENTING OAUTH 2.0 FLOWS IN EMBER
§ Torii and ESA are a winning combination
− They integrate nicely into your Ember application
− Torii handles the OAuth 2.0 flows, and ESA handles the session management
§ Torii offers plenty of authenticators out of the box

− Torii takes care of security best practices (e.g. using and checking the state parameter)
− Make sure to follow this when you build a custom provider
§ Remember that the frontend is only one part of the story

− The backend is responsible for processing the tokens / codes
− Additional security checks should be performed in the backend as well
SECURITY BEST PRACTICES
§ Use the authorization code flow
− By know you should know why
− Run it over HTTPS, no excuses
§ Limit the exposure of your access tokens

− For authentication, throw them away after use
− For continuous API access, consider encrypting them before storing
§ Take care of the little details when implementing an OAuth 2.0 flow
− Verify all data coming from the client before using it
− Limit the scope to what you need
NOW IT’S UP TO YOU …
Secure Follow Share
@baaz balint@balinterdi.com @PhilippeDeRyck philippe.deryck@cs.kuleuven.be

https://balinterdi.com/ /in/balinterdi https://www.websec.be /in/philippederyck

OAuth - Balint Erdi and Philippe de Ryck

Загружено:

Сведения о документе

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

OAuth - Balint Erdi and Philippe de Ryck

Загружено:

Авторское право:

Доступные форматы

SECURE AUTHENTICATION

WITH OAUTH 2.0 IN

§ Author of the popular book Rock and Roll with Ember.js

§ My security expertise is broad, with a focus on Web Security

§ In the coming hours, we will dive deep into OAuth 2.0

§ If you have any questions, don’t wait to ask them!

§ Hands-on experience with implementing OAuth 2.0 authentication in Ember

§ Detailed overview of common threats against OAuth 2.0 flows

I want to access I want to access

Sure, here’s my accountant Sure, here’s an

Rock & Roll

§ Remember that OAuth 2.0 is all about delegation

§ What makes OAuth 2.0 (and authentication) complex is this delegation

2 Give me access to your FB user info

5 Here’s a token to get my info

4 OK, here’s a token that grants access

3 I want to give R&R access to my FB user info Facebook

§ Putting OAuth 2.0 roles in context for authentication

I want to access the I want access as user

5 User info 3 OK, here’s a token that

User Agent 4 Please login

User Agent 4 Please login

3 Access API 1 I want access as myself

4 info 2 OK, here’s a token for that

§ There is a lot of conflicting advice out there

§ To support different authentication strategies, authenticators are used

§ To support authorization, various mixins are provided

§ Torii makes powerful abstractions from complex flows

§ Custom ESA authenticators delegate the flow to a Torii provider

§ This is exactly what you will do in this workshop

§ For this workshop, we have already implemented the backend endpoints

§ All of the lab sessions are fully documented

§ The backend is running on Heroku, and is shared for everyone

Guides for the lab sessions

§ OAuth 2.0 can effectively be used for authentication

§ The backend also plays an important role in the authentication process

§ For authentication, the access token is only needed once

User Agent 4 Please login

User Agent 4 Please login

User Agent 4 Please login

§ Many backend systems need continuous access to the protected resource

§ The risk of theft is even greater with refresh tokens

§ The client ID is used to identify the client

§ The client secret is used to authenticate the client

User Agent 4 Please login

§ Most implicit grant flows easily accept fraudulent tokens

3 Authorize bad client

§ Most implicit grant flows easily accept fraudulent tokens

§ Most implicit grant flows easily accept fraudulent tokens

§ A similar problem exists if the redirect URI can be tampered with

§ Open redirects can be abused to steal tokens as well

§ The authorization code flow handles these problems a lot better

§ Even if an authorization code is stolen, the impact is limited to none

8 User Agent 4 Please login

§ Common parameters to configure the flow

§ These permissions are associated with the access token

User Agent Authorization

9 User info 2 OK, go to FB please

§ The consequence of this attack is very subtle

§ The root cause is the separation between initialization and finalization

9 User info 2 OK, go to FB please

§ Limit the scope of the access token

§ Ensure the integrity of an OAuth 2.0 flow

§ We are going to investigate the security properties of the different flows