SlideShare a Scribd company logo
Secure Authentication and Authorization for Web APIs
OAuth 2.0
• OAuth is an Open standard for Authorization.
• Provides applications (client or server) a secure delegated access to resources on (another) server on behalf of the resource owner.
• Specifies a process for resource owners to authorize third-party access to their server resources without sharing their credentials.
• Designed specifically to work with HTTP, OAuth allows Access Tokens to be issued to third-party applications by an authorization server, with
the approval of the resource owner. The applications then use the access token to access protected resources on a resource server.
• The best analogy to understand OAuth is that of today’s more advanced cars which allow the owner to provide limited access to Valets when
the car keys are given to them. Examples of such limited access are: Maximum Speed, Maximum Distance, Cannot Open Trunk, etc. OAuth is
here to serve a similar purpose with web applications.
• Even though this was not the original intent at the time of its creation, OAuth is also commonly used as a way for internet users to login to
third party websites using their Microsoft, Google, Facebook or Twitter accounts without exposing their password. This is called Federated
Authentication.
• OAuth 2.0 is the widely used protocol currently and is not backwards compatible with OAuth 1.0.
Introduction to OAuth
• Getting access to a user’s social graph — their Facebook friends,
people they’re following on Twitter, or their Google Contacts.
• Sharing information about a user’s activities on your site by posting to
their Facebook wall or Twitter stream.
• Accessing a user’s Google Docs or Dropbox account to store data in
their online file system of choice.
• Integrating business applications with one another to drive smarter
decisions by mashing up multiple data sources such as a Salesforce
CRM and TripIt travel plan.
OAuth Usage Examples
• When Google first released the Google Calendar API, it provided the ability for application developers to read and manipulate a
user’s Google Calendar. However, the only way for a user to provide delegated access was to give the application his or her
account username and password, which the application would then use with Google’s proprietary ClientLogin protocol.
• Proprietary protocols like ClientLogin and standard protocols like HTTP Basic authentication resulted in both small and big
applications requesting passwords from users to get access to their data. This wasn’t affecting just desktop apps—applications all
over the Web were prompting for credentials.
• Flickr, an online photo-sharing site, was one such application. Originally an independent company, Flickr was acquired by Yahoo! a
few years after Google bought Blogger. The idea of Yahoo! asking for Google user passwords scared both firms, leading to the
development of new proprietary protocols that tackled this problem on the Web.
• With new protocols, such as Google’s AuthSub and Yahoo!’s BBAuth, an application would redirect users to an authorization page
on the provider’s site if the app needed access to user data. Users would log in to their accounts and grant access, and then the
application would get a token to use for accessing the users’ data.
• While this solved some security issues, it also created costs for developers. Developers integrating with multiple major API
providers had to learn and implement several web-based authorization protocols in their applications. Startups building new APIs
were not comfortable implementing the proprietary auth schemes, nor developing their own custom schemes, which might
introduce security vulnerabilities. Instead, these startups and major API providers decided that they needed to create a standard
protocol to improve consistency for these web-based authorization flows. And that’s how OAuth was born.
How OAuth was born?
• With wide adoption of collaboration platforms and social networks, application developers have the
opportunity to connect users with their data wherever they are on the Web.
• Connecting users with their data results in improved day-to-day efficiency by eliminating data silos
and also allows developers to differentiate their applications from the competition.
• OAuth provides the ability for these applications to access a user’s data securely, without requiring
the user to take the scary step of handing over an account password.
• There are over 300 APIs that are popular for containing private user data. In order to access or
update this private data via each of these APIs, an application needs to be delegated access by the
owner of the data. Having a common protocol for handling API authorization greatly improves the
developer experience because it lessens the learning curve required to integrate with a new API.
• An authorization standard creates more confidence in the security of APIs because the standard has
been vetted by a large community.
Why developers should care?
• Trust: A user may not trust providing their password to your application.
• Decreased user sensitivity to phishing: Even if the user is comfortable providing their password to your application,
making the user comfortable doing this around the Web can have negative long-term effects, such as making phishing
scams more effective.
• Expanded access and risk: When the user provides their password to your application, you get access to not only the
data your application needs, but all other data in the user’s account. The application has an obligation to its users to
securely store these passwords and prevent them from leaking. Many developers do not want the risk exposure of having
this additional responsibility.
• Limited reliability: When a user changes their password, your application no longer has access to their data.
• Revocation challenges: The only way a user can revoke access to your application is by changing their password, which
also revokes access to all other apps. If OAuth is used, access to a particular app can be revoked without changing any
passwords.
• Passwords become required (Cannot do OpenID): When an API provider supports federated authentication mechanisms,
users may not have passwords on their accounts. If passwords become required, this could potentially mean a huge risk
for the API provider. Also, if an API provider requires passwords for API authentication, it becomes challenging to improve
account security with technologies like CAPTCHAs or multifactor authentication (such as one-time password tokens).
What’s wrong with Passwords?
• Authentication: Process of verifying the identity of a user—knowing that the user is who
they claim to be. In the real world, when a police officer asks for your identification, she’s
verifying your identity by ensuring that the picture on your identification matches your
likeness.
• Authorization: Process of verifying that a user has the right to perform some action, such
as reading a document or accessing an email account. This typically first requires valid
identification of the user (authentication) before checking whether the user is authorized.
• Federated Authentication: Although many applications have their own system of accounts
(including usernames and passwords), some applications rely on other services to verify
the identity of users. This is called federated authentication.
• Delegated Authorization: Delegated authorization is granting access to another person or
application to perform actions (or at least some actions) on your behalf.
Key Terminology
• Resource server: The server hosting user-owned resources that are protected by OAuth.
This is typically an API provider that holds and protects data such as photos, videos,
calendars, or contacts.
• Resource Owner: Typically the user of an application, the resource owner has the ability to
grant access to their own data hosted on the resource server.
• Client: An application making API requests to perform actions on protected resources on
behalf of the resource owner and with its authorization. Clients, most of the times, are
required to be registered with the Authorization server (see below) and in the process,
clients are assigned with a Client ID and in some cases, a Client Secret.
• Authorization Server: The authorization server gets consent from the resource owner and
issues bearer access tokens to clients for accessing protected resources hosted by a
resource server. Smaller API providers may use the same application and URL space for
both the authorization server and resource server.
Roles
• Although signing requests is required by some APIs (especially the ones still on OAuth 1.0), most APIs
out there do not require requests to be signed. They require only Bearer Tokens.
• Bearer Tokens are a type of access token whereby simple possession of the token provides access to
protected resources.
• After obtaining a bearer token, the token can be sent along with your requests in one of several
ways. The preferred method of authorizing requests is by sending the access token in a HTTP
Authorization header:
• The Authorization header is the preferred mechanism because:
• The header is rarely logged by proxy servers and web server access logs.
• The header is almost never cached.
• The header doesn’t get stored in the browser cache when making requests from the client.
• Other Mechanisms (not so widely supported) include Query Parameters and Form-encoded Body
Parameters.
Bearer Tokens
• When OAuth 1.0 was developed in 2007, it was decided that cryptographic signatures were
necessary to support the security of the APIs. And the APIs were hosted at vanilla HTTP endpoints.
• Over the years, SSL / TLS became a more common way of protecting the APIs (from a transport
perspective) and the need for signatures decreased.
• OAuth 2.0, especially because its mechanism of authentication is a bearer token, mandates the use
of SSL / TSL.
• When implementing OAuth 2.0, a developer should verify that the application properly handles SSL /
TLS certificate chain by doing the following:
• Checking that the hostname on the certificate returned by the server matches the hostname in the URL being accessed
• Verifying each certificate in the chain properly chains up to a valid and trusted certificate authority (CA)
• Ensuring that the certificate authority bundle on your server is secure and not able to be modified by potential attackers.
SSL / TLS
• Server-side Web Application: An OAuth client running on a web server. The web
application is accessed by a resource owner (user) and the application makes the
appropriate API calls using a server-side programming language. The user has no access to
the OAuth client secret or any access tokens issued by the authorization server.
• Client-side application running in a web browser: An OAuth client running in a user’s web
browser, where the client has access to the application code and/or API requests. The
application could be distributed as JavaScript included in a web page, as a browser
extension, or using a plug-in technology such as Flash. The OAuth credentials are not
trusted to be kept confidential from the resource owner, so some API providers won’t issue
client secrets for applications using this profile.
• Native Application: An OAuth client which is very similar to the client-side application, as
the credentials are not trusted to be kept confidential. However, since it’s an installed
application, it may not have access to the full capabilities of a web browser.
Client Profiles
Client Registration Example
Client Type Authorization Flow
Server-side Web Application Authorization Code Grant
Third-Party Browser-based Client-side Applications Implicit Grant
First-Party Clients (browser-based and Native) Resource Owner Password Grant
Clients accessing Resources as themselves Client Credentials Grant
Native Applications (with a Backend Web Server) Authorization Code Grant or Implicit Grant
Native Applications (without a Backend Web
Server)
A custom flow that looks like Authorization Code
Grant or Implicit Grant but gets tricky.
Authorization Flows
Each of the client profiles needs to be accommodated with an appropriate protocol flow for obtaining authorization from the
resource owner for access to their data. The core OAuth 2.0 protocol defines four primary “grant types” used for obtaining
authorization.
• The resource owner is first redirected by the application to the OAuth authorization server at the API provider.
• The authorization server checks to see if the user has an active session. If he / she does, the authorization server prompts
her for access to the requested data. If he / she doesn’t, then the user is asked to login with a username and password
and then prompts for access.
• After she grants access, she is redirected back to the web application and an authorization code is included in the URL as
the code query parameter:
http://www.example.com/oauth_callback?code=ABC1234
• Because the code is passed as a query parameter, the web browser sends it along to the web server that is acting as the
OAuth client. This authorization code is then exchanged for an access token using a server-to-server call from the
application to the authorization server. This access token is used by the client to make API calls.
• Should be used when:
• Long-lived access is required. Supports Refresh Tokens.
• The OAuth client is a web application server.
• Accountability for API calls is very important and the OAuth token shouldn’t be leaked to the browser, where the user may have
access to it.
Authorization Code Grant
Authorization Code Grant
• The Implicit Grant flow used widely for browser-based client-side web applications
is very simple.
• In this flow, an access token is immediately returned to the application after a user
grants the requested authorization. An intermediate authorization code is not
required as it is in the server-side Web Application flow.
• Should be used when:
• Only temporary access to data is required. Does not accommodate Refresh Tokens.
• The user is regularly logged into the API provider.
• The OAuth client is running in the browser (using JavaScript, Flash, etc.).
• The browser is strongly trusted and there is limited concern that the access token will leak
to untrusted users or applications.
Implicit Grant
Implicit Grant
• The Resource Owner Password Credentials flow allows exchanging the username and password of a
user for an access token and, optionally, a refresh token.
• This flow has significantly different security properties than the other OAuth flows. The primary
difference is that the user’s password is accessible to the application.
• This requires strong trust of the application by the user.
• The main difference between Password-based apps that have been around in the last two decades
and these new OAuth 2.0 specified Password-based apps are that these new ones use Bearer Tokens
and not Session Cookies.
• Should be used when:
• Because the resource owner’s password is exposed to the application, this flow should be used sparingly.
• It is recommended only for first-party “official” applications released by the API provider, and not opened up to
wider third-party developer communities.
Resource Owner Password Grant
Resource Owner Password Grant
• Most of the OAuth flows are for handling delegated authorization, when a resource owner grants
access to an application to access her data.
• However, there are cases when the client itself owns the data and does not need delegated access
from a resource owner, or delegated access has already been granted to the application outside of a
typical OAuth flow.
• The only popular example using this is Facebook AppLogin.
• Should be used when:
• Imagine a storage API, such as Google Storage or Amazon S3. You’re building an application that has resources (data
files, images, etc.) stored externally to your app using one of these APIs.
• The application needs to read and update these resources, but acting on behalf of the app itself rather than on
behalf of any individual user.
• This is a perfect use case for the Client Credentials flow.
• The application can ask the OAuth authorization server for an access token directly, without the involvement of any
end user.
Client Credentials Grant
Client Credentials Grant
Q & A

More Related Content

What's hot

Service Oriented Architecture Luqman
Service Oriented Architecture LuqmanService Oriented Architecture Luqman
Service Oriented Architecture Luqman
Luqman Shareef
 
Restful Services
Restful ServicesRestful Services
Restful Services
SHAKIL AKHTAR
 
Oracle UCM Implementation Patterns
Oracle UCM Implementation PatternsOracle UCM Implementation Patterns
Oracle UCM Implementation Patterns
Brian Huff
 
Restful web-services
Restful web-servicesRestful web-services
Restful web-services
rporwal
 
Top 10 Ways To Integrate With Oracle Enterprise Content Management (ECM)
Top 10 Ways To Integrate With Oracle Enterprise Content Management (ECM)Top 10 Ways To Integrate With Oracle Enterprise Content Management (ECM)
Top 10 Ways To Integrate With Oracle Enterprise Content Management (ECM)
Brian Huff
 
SOA: What It Means To The Enterprise
SOA: What It Means To The EnterpriseSOA: What It Means To The Enterprise
SOA: What It Means To The Enterprise
WSO2
 
Creating and Maintaining An Internationalized Website
Creating and Maintaining An Internationalized WebsiteCreating and Maintaining An Internationalized Website
Creating and Maintaining An Internationalized Website
Brian Huff
 
Running an erlang based messaging system on AWS
Running an erlang based messaging system on AWSRunning an erlang based messaging system on AWS
Running an erlang based messaging system on AWS
Lahav Savir
 
NetCache Accelerates Web Servers
NetCache Accelerates Web ServersNetCache Accelerates Web Servers
NetCache Accelerates Web Servers
webhostingguy
 
Exchange online real world migration challenges
Exchange online real world migration challengesExchange online real world migration challenges
Exchange online real world migration challenges
Steve Goodman
 
DODN2009 - Architecting Modern Distributed Applications
DODN2009 - Architecting Modern Distributed ApplicationsDODN2009 - Architecting Modern Distributed Applications
DODN2009 - Architecting Modern Distributed Applications
Clint Edmonson
 
Cloud presentation NELA
Cloud presentation NELACloud presentation NELA
Cloud presentation NELA
Edward Iglesias
 
Oracle UCM: Web Site Performance Tuning
Oracle UCM: Web Site Performance TuningOracle UCM: Web Site Performance Tuning
Oracle UCM: Web Site Performance Tuning
Brian Huff
 
Secured REST Microservices with Spring Cloud
Secured REST Microservices with Spring CloudSecured REST Microservices with Spring Cloud
Secured REST Microservices with Spring Cloud
Orkhan Gasimov
 
DevLink - Architecting Modern Distributed Applications
DevLink - Architecting Modern Distributed ApplicationsDevLink - Architecting Modern Distributed Applications
DevLink - Architecting Modern Distributed Applications
Clint Edmonson
 
Patterns of Distributed Application Design
Patterns of Distributed Application DesignPatterns of Distributed Application Design
Patterns of Distributed Application Design
Orkhan Gasimov
 
The eBay Architecture: Striking a Balance between Site Stability, Feature Ve...
The eBay Architecture:  Striking a Balance between Site Stability, Feature Ve...The eBay Architecture:  Striking a Balance between Site Stability, Feature Ve...
The eBay Architecture: Striking a Balance between Site Stability, Feature Ve...
Randy Shoup
 
E commerce
E commerceE commerce
E commerce
Ambili Baby
 
RavenDB overview
RavenDB overviewRavenDB overview
RavenDB overview
Igor Moochnick
 
Stop Those Prying Eyes Getting To Your Data SPTechCon
Stop Those Prying Eyes Getting To Your Data SPTechConStop Those Prying Eyes Getting To Your Data SPTechCon
Stop Those Prying Eyes Getting To Your Data SPTechCon
Liam Cleary [MVP]
 

What's hot (20)

Service Oriented Architecture Luqman
Service Oriented Architecture LuqmanService Oriented Architecture Luqman
Service Oriented Architecture Luqman
 
Restful Services
Restful ServicesRestful Services
Restful Services
 
Oracle UCM Implementation Patterns
Oracle UCM Implementation PatternsOracle UCM Implementation Patterns
Oracle UCM Implementation Patterns
 
Restful web-services
Restful web-servicesRestful web-services
Restful web-services
 
Top 10 Ways To Integrate With Oracle Enterprise Content Management (ECM)
Top 10 Ways To Integrate With Oracle Enterprise Content Management (ECM)Top 10 Ways To Integrate With Oracle Enterprise Content Management (ECM)
Top 10 Ways To Integrate With Oracle Enterprise Content Management (ECM)
 
SOA: What It Means To The Enterprise
SOA: What It Means To The EnterpriseSOA: What It Means To The Enterprise
SOA: What It Means To The Enterprise
 
Creating and Maintaining An Internationalized Website
Creating and Maintaining An Internationalized WebsiteCreating and Maintaining An Internationalized Website
Creating and Maintaining An Internationalized Website
 
Running an erlang based messaging system on AWS
Running an erlang based messaging system on AWSRunning an erlang based messaging system on AWS
Running an erlang based messaging system on AWS
 
NetCache Accelerates Web Servers
NetCache Accelerates Web ServersNetCache Accelerates Web Servers
NetCache Accelerates Web Servers
 
Exchange online real world migration challenges
Exchange online real world migration challengesExchange online real world migration challenges
Exchange online real world migration challenges
 
DODN2009 - Architecting Modern Distributed Applications
DODN2009 - Architecting Modern Distributed ApplicationsDODN2009 - Architecting Modern Distributed Applications
DODN2009 - Architecting Modern Distributed Applications
 
Cloud presentation NELA
Cloud presentation NELACloud presentation NELA
Cloud presentation NELA
 
Oracle UCM: Web Site Performance Tuning
Oracle UCM: Web Site Performance TuningOracle UCM: Web Site Performance Tuning
Oracle UCM: Web Site Performance Tuning
 
Secured REST Microservices with Spring Cloud
Secured REST Microservices with Spring CloudSecured REST Microservices with Spring Cloud
Secured REST Microservices with Spring Cloud
 
DevLink - Architecting Modern Distributed Applications
DevLink - Architecting Modern Distributed ApplicationsDevLink - Architecting Modern Distributed Applications
DevLink - Architecting Modern Distributed Applications
 
Patterns of Distributed Application Design
Patterns of Distributed Application DesignPatterns of Distributed Application Design
Patterns of Distributed Application Design
 
The eBay Architecture: Striking a Balance between Site Stability, Feature Ve...
The eBay Architecture:  Striking a Balance between Site Stability, Feature Ve...The eBay Architecture:  Striking a Balance between Site Stability, Feature Ve...
The eBay Architecture: Striking a Balance between Site Stability, Feature Ve...
 
E commerce
E commerceE commerce
E commerce
 
RavenDB overview
RavenDB overviewRavenDB overview
RavenDB overview
 
Stop Those Prying Eyes Getting To Your Data SPTechCon
Stop Those Prying Eyes Getting To Your Data SPTechConStop Those Prying Eyes Getting To Your Data SPTechCon
Stop Those Prying Eyes Getting To Your Data SPTechCon
 

Viewers also liked

Garden State HS Wrestling Champions
Garden State HS Wrestling ChampionsGarden State HS Wrestling Champions
Garden State HS Wrestling Champions
JIm Traxinger
 
In-Vitro Paper
In-Vitro PaperIn-Vitro Paper
In-Vitro Paper
Jennifer Quinn
 
Caminante Proyecto Educativo and The Re...Dominican Republic - Global Ministr...
Caminante Proyecto Educativo and The Re...Dominican Republic - Global Ministr...Caminante Proyecto Educativo and The Re...Dominican Republic - Global Ministr...
Caminante Proyecto Educativo and The Re...Dominican Republic - Global Ministr...
Ashley Holst
 
El sueno
El suenoEl sueno
El sueno
yudy7777
 
Tarea 5 motivacion_judithazuaje
Tarea 5 motivacion_judithazuajeTarea 5 motivacion_judithazuaje
Tarea 5 motivacion_judithazuaje
yudy7777
 
Presentation 2
Presentation 2Presentation 2
Presentation 2
Meerwise Joya
 
Basic android
Basic androidBasic android
Basic android
Dharmendra Kushwaha
 
SinglePageApplications
SinglePageApplicationsSinglePageApplications
SinglePageApplications
Adi Challa
 
CHURCH AND SOCIETY--Table and Intoduction
CHURCH AND SOCIETY--Table and IntoductionCHURCH AND SOCIETY--Table and Intoduction
CHURCH AND SOCIETY--Table and Intoduction
Rudi Maier
 
Scuolasicura
ScuolasicuraScuolasicura
Scuolasicura
scuolabloggando
 
Pennsylvanian 1-19-79
Pennsylvanian 1-19-79Pennsylvanian 1-19-79
Pennsylvanian 1-19-79
JIm Traxinger
 
No morebullconferencefeb2015
No morebullconferencefeb2015No morebullconferencefeb2015
No morebullconferencefeb2015
AlbertaHelpingAnimalsSociety
 
NJ Wrestling Region 4 Champions
NJ Wrestling Region 4 ChampionsNJ Wrestling Region 4 Champions
NJ Wrestling Region 4 Champions
JIm Traxinger
 
Presentation 4
Presentation 4Presentation 4
Presentation 4
Meerwise Joya
 
NoSQLDatabases
NoSQLDatabasesNoSQLDatabases
NoSQLDatabases
Adi Challa
 
J.Levy Persentation - M3
J.Levy Persentation - M3J.Levy Persentation - M3
J.Levy Persentation - M3
Jacob Levy
 
La storia è di tutti
La storia è di tuttiLa storia è di tutti
La storia è di tutti
scuolabloggando
 
Riscopriamo il mondo contadino della Maremma Settentrionale
Riscopriamo il mondo contadino  della Maremma SettentrionaleRiscopriamo il mondo contadino  della Maremma Settentrionale
Riscopriamo il mondo contadino della Maremma Settentrionale
scuolabloggando
 
1979 EIWA Championship
1979 EIWA Championship1979 EIWA Championship
1979 EIWA Championship
JIm Traxinger
 

Viewers also liked (20)

Garden State HS Wrestling Champions
Garden State HS Wrestling ChampionsGarden State HS Wrestling Champions
Garden State HS Wrestling Champions
 
In-Vitro Paper
In-Vitro PaperIn-Vitro Paper
In-Vitro Paper
 
Caminante Proyecto Educativo and The Re...Dominican Republic - Global Ministr...
Caminante Proyecto Educativo and The Re...Dominican Republic - Global Ministr...Caminante Proyecto Educativo and The Re...Dominican Republic - Global Ministr...
Caminante Proyecto Educativo and The Re...Dominican Republic - Global Ministr...
 
El sueno
El suenoEl sueno
El sueno
 
Tarea 5 motivacion_judithazuaje
Tarea 5 motivacion_judithazuajeTarea 5 motivacion_judithazuaje
Tarea 5 motivacion_judithazuaje
 
Presentation 2
Presentation 2Presentation 2
Presentation 2
 
Basic android
Basic androidBasic android
Basic android
 
SinglePageApplications
SinglePageApplicationsSinglePageApplications
SinglePageApplications
 
CHURCH AND SOCIETY--Table and Intoduction
CHURCH AND SOCIETY--Table and IntoductionCHURCH AND SOCIETY--Table and Intoduction
CHURCH AND SOCIETY--Table and Intoduction
 
Scuolasicura
ScuolasicuraScuolasicura
Scuolasicura
 
Pennsylvanian 1-19-79
Pennsylvanian 1-19-79Pennsylvanian 1-19-79
Pennsylvanian 1-19-79
 
No morebullconferencefeb2015
No morebullconferencefeb2015No morebullconferencefeb2015
No morebullconferencefeb2015
 
NJ Wrestling Region 4 Champions
NJ Wrestling Region 4 ChampionsNJ Wrestling Region 4 Champions
NJ Wrestling Region 4 Champions
 
Un fantasma a...scuola
Un fantasma a...scuolaUn fantasma a...scuola
Un fantasma a...scuola
 
Presentation 4
Presentation 4Presentation 4
Presentation 4
 
NoSQLDatabases
NoSQLDatabasesNoSQLDatabases
NoSQLDatabases
 
J.Levy Persentation - M3
J.Levy Persentation - M3J.Levy Persentation - M3
J.Levy Persentation - M3
 
La storia è di tutti
La storia è di tuttiLa storia è di tutti
La storia è di tutti
 
Riscopriamo il mondo contadino della Maremma Settentrionale
Riscopriamo il mondo contadino  della Maremma SettentrionaleRiscopriamo il mondo contadino  della Maremma Settentrionale
Riscopriamo il mondo contadino della Maremma Settentrionale
 
1979 EIWA Championship
1979 EIWA Championship1979 EIWA Championship
1979 EIWA Championship
 

Similar to OAuth

OAuth
OAuthOAuth
OAuth
Tom Elrod
 
Ladies Be Architects - Study Group III: OAuth 2.0 (Ep 1)
Ladies Be Architects - Study Group III: OAuth 2.0 (Ep 1)Ladies Be Architects - Study Group III: OAuth 2.0 (Ep 1)
Ladies Be Architects - Study Group III: OAuth 2.0 (Ep 1)
gemziebeth
 
Oauth2.0
Oauth2.0Oauth2.0
Oauth2.0
Yasmine Gaber
 
Oauth2 and OWSM OAuth2 support
Oauth2 and OWSM OAuth2 supportOauth2 and OWSM OAuth2 support
Oauth2 and OWSM OAuth2 support
Gaurav Sharma
 
Intro to OAuth2 and OpenID Connect
Intro to OAuth2 and OpenID ConnectIntro to OAuth2 and OpenID Connect
Intro to OAuth2 and OpenID Connect
LiamWadman
 
oauth-for-credentials-security-in-rest-api-access
oauth-for-credentials-security-in-rest-api-accessoauth-for-credentials-security-in-rest-api-access
oauth-for-credentials-security-in-rest-api-access
idsecconf
 
CIS13: Introduction to OAuth 2.0
CIS13: Introduction to OAuth 2.0CIS13: Introduction to OAuth 2.0
CIS13: Introduction to OAuth 2.0
CloudIDSummit
 
Introduction to OAuth2.0
Introduction to OAuth2.0Introduction to OAuth2.0
Introduction to OAuth2.0
Oracle Corporation
 
Oauth Behind The Scenes
Oauth Behind The Scenes Oauth Behind The Scenes
Oauth Behind The Scenes
Thang Tran Duc
 
.NET Core, ASP.NET Core Course, Session 19
 .NET Core, ASP.NET Core Course, Session 19 .NET Core, ASP.NET Core Course, Session 19
.NET Core, ASP.NET Core Course, Session 19
aminmesbahi
 
Introduction to Azure AD and Azure AD B2C
Introduction to Azure AD and Azure AD B2CIntroduction to Azure AD and Azure AD B2C
Introduction to Azure AD and Azure AD B2C
Joonas Westlin
 
API Security with OAuth2.0.
API Security with OAuth2.0.API Security with OAuth2.0.
API Security with OAuth2.0.
Kellton Tech Solutions Ltd
 
Oracle APEX Social Login
Oracle APEX Social LoginOracle APEX Social Login
Oracle APEX Social Login
msewtz
 
Securing SharePoint Apps with OAuth
Securing SharePoint Apps with OAuthSecuring SharePoint Apps with OAuth
Securing SharePoint Apps with OAuth
Kashif Imran
 
O auth 2
O auth 2O auth 2
O auth 2
Nisha Baswal
 
CIS13: Bootcamp: Ping Identity OAuth and OpenID Connect In Action with PingFe...
CIS13: Bootcamp: Ping Identity OAuth and OpenID Connect In Action with PingFe...CIS13: Bootcamp: Ping Identity OAuth and OpenID Connect In Action with PingFe...
CIS13: Bootcamp: Ping Identity OAuth and OpenID Connect In Action with PingFe...
CloudIDSummit
 
Implementing Microservices Security Patterns & Protocols with Spring
Implementing Microservices Security Patterns & Protocols with SpringImplementing Microservices Security Patterns & Protocols with Spring
Implementing Microservices Security Patterns & Protocols with Spring
VMware Tanzu
 
OAuth2 Implementation Presentation (Java)
OAuth2 Implementation Presentation (Java)OAuth2 Implementation Presentation (Java)
OAuth2 Implementation Presentation (Java)
Knoldus Inc.
 
Dev Dives: Master advanced authentication and performance in Productivity Act...
Dev Dives: Master advanced authentication and performance in Productivity Act...Dev Dives: Master advanced authentication and performance in Productivity Act...
Dev Dives: Master advanced authentication and performance in Productivity Act...
UiPathCommunity
 
OAuth 2.0 and OpenId Connect
OAuth 2.0 and OpenId ConnectOAuth 2.0 and OpenId Connect
OAuth 2.0 and OpenId Connect
Saran Doraiswamy
 

Similar to OAuth (20)

OAuth
OAuthOAuth
OAuth
 
Ladies Be Architects - Study Group III: OAuth 2.0 (Ep 1)
Ladies Be Architects - Study Group III: OAuth 2.0 (Ep 1)Ladies Be Architects - Study Group III: OAuth 2.0 (Ep 1)
Ladies Be Architects - Study Group III: OAuth 2.0 (Ep 1)
 
Oauth2.0
Oauth2.0Oauth2.0
Oauth2.0
 
Oauth2 and OWSM OAuth2 support
Oauth2 and OWSM OAuth2 supportOauth2 and OWSM OAuth2 support
Oauth2 and OWSM OAuth2 support
 
Intro to OAuth2 and OpenID Connect
Intro to OAuth2 and OpenID ConnectIntro to OAuth2 and OpenID Connect
Intro to OAuth2 and OpenID Connect
 
oauth-for-credentials-security-in-rest-api-access
oauth-for-credentials-security-in-rest-api-accessoauth-for-credentials-security-in-rest-api-access
oauth-for-credentials-security-in-rest-api-access
 
CIS13: Introduction to OAuth 2.0
CIS13: Introduction to OAuth 2.0CIS13: Introduction to OAuth 2.0
CIS13: Introduction to OAuth 2.0
 
Introduction to OAuth2.0
Introduction to OAuth2.0Introduction to OAuth2.0
Introduction to OAuth2.0
 
Oauth Behind The Scenes
Oauth Behind The Scenes Oauth Behind The Scenes
Oauth Behind The Scenes
 
.NET Core, ASP.NET Core Course, Session 19
 .NET Core, ASP.NET Core Course, Session 19 .NET Core, ASP.NET Core Course, Session 19
.NET Core, ASP.NET Core Course, Session 19
 
Introduction to Azure AD and Azure AD B2C
Introduction to Azure AD and Azure AD B2CIntroduction to Azure AD and Azure AD B2C
Introduction to Azure AD and Azure AD B2C
 
API Security with OAuth2.0.
API Security with OAuth2.0.API Security with OAuth2.0.
API Security with OAuth2.0.
 
Oracle APEX Social Login
Oracle APEX Social LoginOracle APEX Social Login
Oracle APEX Social Login
 
Securing SharePoint Apps with OAuth
Securing SharePoint Apps with OAuthSecuring SharePoint Apps with OAuth
Securing SharePoint Apps with OAuth
 
O auth 2
O auth 2O auth 2
O auth 2
 
CIS13: Bootcamp: Ping Identity OAuth and OpenID Connect In Action with PingFe...
CIS13: Bootcamp: Ping Identity OAuth and OpenID Connect In Action with PingFe...CIS13: Bootcamp: Ping Identity OAuth and OpenID Connect In Action with PingFe...
CIS13: Bootcamp: Ping Identity OAuth and OpenID Connect In Action with PingFe...
 
Implementing Microservices Security Patterns & Protocols with Spring
Implementing Microservices Security Patterns & Protocols with SpringImplementing Microservices Security Patterns & Protocols with Spring
Implementing Microservices Security Patterns & Protocols with Spring
 
OAuth2 Implementation Presentation (Java)
OAuth2 Implementation Presentation (Java)OAuth2 Implementation Presentation (Java)
OAuth2 Implementation Presentation (Java)
 
Dev Dives: Master advanced authentication and performance in Productivity Act...
Dev Dives: Master advanced authentication and performance in Productivity Act...Dev Dives: Master advanced authentication and performance in Productivity Act...
Dev Dives: Master advanced authentication and performance in Productivity Act...
 
OAuth 2.0 and OpenId Connect
OAuth 2.0 and OpenId ConnectOAuth 2.0 and OpenId Connect
OAuth 2.0 and OpenId Connect
 

OAuth

  • 1. Secure Authentication and Authorization for Web APIs OAuth 2.0
  • 2. • OAuth is an Open standard for Authorization. • Provides applications (client or server) a secure delegated access to resources on (another) server on behalf of the resource owner. • Specifies a process for resource owners to authorize third-party access to their server resources without sharing their credentials. • Designed specifically to work with HTTP, OAuth allows Access Tokens to be issued to third-party applications by an authorization server, with the approval of the resource owner. The applications then use the access token to access protected resources on a resource server. • The best analogy to understand OAuth is that of today’s more advanced cars which allow the owner to provide limited access to Valets when the car keys are given to them. Examples of such limited access are: Maximum Speed, Maximum Distance, Cannot Open Trunk, etc. OAuth is here to serve a similar purpose with web applications. • Even though this was not the original intent at the time of its creation, OAuth is also commonly used as a way for internet users to login to third party websites using their Microsoft, Google, Facebook or Twitter accounts without exposing their password. This is called Federated Authentication. • OAuth 2.0 is the widely used protocol currently and is not backwards compatible with OAuth 1.0. Introduction to OAuth
  • 3. • Getting access to a user’s social graph — their Facebook friends, people they’re following on Twitter, or their Google Contacts. • Sharing information about a user’s activities on your site by posting to their Facebook wall or Twitter stream. • Accessing a user’s Google Docs or Dropbox account to store data in their online file system of choice. • Integrating business applications with one another to drive smarter decisions by mashing up multiple data sources such as a Salesforce CRM and TripIt travel plan. OAuth Usage Examples
  • 4. • When Google first released the Google Calendar API, it provided the ability for application developers to read and manipulate a user’s Google Calendar. However, the only way for a user to provide delegated access was to give the application his or her account username and password, which the application would then use with Google’s proprietary ClientLogin protocol. • Proprietary protocols like ClientLogin and standard protocols like HTTP Basic authentication resulted in both small and big applications requesting passwords from users to get access to their data. This wasn’t affecting just desktop apps—applications all over the Web were prompting for credentials. • Flickr, an online photo-sharing site, was one such application. Originally an independent company, Flickr was acquired by Yahoo! a few years after Google bought Blogger. The idea of Yahoo! asking for Google user passwords scared both firms, leading to the development of new proprietary protocols that tackled this problem on the Web. • With new protocols, such as Google’s AuthSub and Yahoo!’s BBAuth, an application would redirect users to an authorization page on the provider’s site if the app needed access to user data. Users would log in to their accounts and grant access, and then the application would get a token to use for accessing the users’ data. • While this solved some security issues, it also created costs for developers. Developers integrating with multiple major API providers had to learn and implement several web-based authorization protocols in their applications. Startups building new APIs were not comfortable implementing the proprietary auth schemes, nor developing their own custom schemes, which might introduce security vulnerabilities. Instead, these startups and major API providers decided that they needed to create a standard protocol to improve consistency for these web-based authorization flows. And that’s how OAuth was born. How OAuth was born?
  • 5. • With wide adoption of collaboration platforms and social networks, application developers have the opportunity to connect users with their data wherever they are on the Web. • Connecting users with their data results in improved day-to-day efficiency by eliminating data silos and also allows developers to differentiate their applications from the competition. • OAuth provides the ability for these applications to access a user’s data securely, without requiring the user to take the scary step of handing over an account password. • There are over 300 APIs that are popular for containing private user data. In order to access or update this private data via each of these APIs, an application needs to be delegated access by the owner of the data. Having a common protocol for handling API authorization greatly improves the developer experience because it lessens the learning curve required to integrate with a new API. • An authorization standard creates more confidence in the security of APIs because the standard has been vetted by a large community. Why developers should care?
  • 6. • Trust: A user may not trust providing their password to your application. • Decreased user sensitivity to phishing: Even if the user is comfortable providing their password to your application, making the user comfortable doing this around the Web can have negative long-term effects, such as making phishing scams more effective. • Expanded access and risk: When the user provides their password to your application, you get access to not only the data your application needs, but all other data in the user’s account. The application has an obligation to its users to securely store these passwords and prevent them from leaking. Many developers do not want the risk exposure of having this additional responsibility. • Limited reliability: When a user changes their password, your application no longer has access to their data. • Revocation challenges: The only way a user can revoke access to your application is by changing their password, which also revokes access to all other apps. If OAuth is used, access to a particular app can be revoked without changing any passwords. • Passwords become required (Cannot do OpenID): When an API provider supports federated authentication mechanisms, users may not have passwords on their accounts. If passwords become required, this could potentially mean a huge risk for the API provider. Also, if an API provider requires passwords for API authentication, it becomes challenging to improve account security with technologies like CAPTCHAs or multifactor authentication (such as one-time password tokens). What’s wrong with Passwords?
  • 7. • Authentication: Process of verifying the identity of a user—knowing that the user is who they claim to be. In the real world, when a police officer asks for your identification, she’s verifying your identity by ensuring that the picture on your identification matches your likeness. • Authorization: Process of verifying that a user has the right to perform some action, such as reading a document or accessing an email account. This typically first requires valid identification of the user (authentication) before checking whether the user is authorized. • Federated Authentication: Although many applications have their own system of accounts (including usernames and passwords), some applications rely on other services to verify the identity of users. This is called federated authentication. • Delegated Authorization: Delegated authorization is granting access to another person or application to perform actions (or at least some actions) on your behalf. Key Terminology
  • 8. • Resource server: The server hosting user-owned resources that are protected by OAuth. This is typically an API provider that holds and protects data such as photos, videos, calendars, or contacts. • Resource Owner: Typically the user of an application, the resource owner has the ability to grant access to their own data hosted on the resource server. • Client: An application making API requests to perform actions on protected resources on behalf of the resource owner and with its authorization. Clients, most of the times, are required to be registered with the Authorization server (see below) and in the process, clients are assigned with a Client ID and in some cases, a Client Secret. • Authorization Server: The authorization server gets consent from the resource owner and issues bearer access tokens to clients for accessing protected resources hosted by a resource server. Smaller API providers may use the same application and URL space for both the authorization server and resource server. Roles
  • 9. • Although signing requests is required by some APIs (especially the ones still on OAuth 1.0), most APIs out there do not require requests to be signed. They require only Bearer Tokens. • Bearer Tokens are a type of access token whereby simple possession of the token provides access to protected resources. • After obtaining a bearer token, the token can be sent along with your requests in one of several ways. The preferred method of authorizing requests is by sending the access token in a HTTP Authorization header: • The Authorization header is the preferred mechanism because: • The header is rarely logged by proxy servers and web server access logs. • The header is almost never cached. • The header doesn’t get stored in the browser cache when making requests from the client. • Other Mechanisms (not so widely supported) include Query Parameters and Form-encoded Body Parameters. Bearer Tokens
  • 10. • When OAuth 1.0 was developed in 2007, it was decided that cryptographic signatures were necessary to support the security of the APIs. And the APIs were hosted at vanilla HTTP endpoints. • Over the years, SSL / TLS became a more common way of protecting the APIs (from a transport perspective) and the need for signatures decreased. • OAuth 2.0, especially because its mechanism of authentication is a bearer token, mandates the use of SSL / TSL. • When implementing OAuth 2.0, a developer should verify that the application properly handles SSL / TLS certificate chain by doing the following: • Checking that the hostname on the certificate returned by the server matches the hostname in the URL being accessed • Verifying each certificate in the chain properly chains up to a valid and trusted certificate authority (CA) • Ensuring that the certificate authority bundle on your server is secure and not able to be modified by potential attackers. SSL / TLS
  • 11. • Server-side Web Application: An OAuth client running on a web server. The web application is accessed by a resource owner (user) and the application makes the appropriate API calls using a server-side programming language. The user has no access to the OAuth client secret or any access tokens issued by the authorization server. • Client-side application running in a web browser: An OAuth client running in a user’s web browser, where the client has access to the application code and/or API requests. The application could be distributed as JavaScript included in a web page, as a browser extension, or using a plug-in technology such as Flash. The OAuth credentials are not trusted to be kept confidential from the resource owner, so some API providers won’t issue client secrets for applications using this profile. • Native Application: An OAuth client which is very similar to the client-side application, as the credentials are not trusted to be kept confidential. However, since it’s an installed application, it may not have access to the full capabilities of a web browser. Client Profiles
  • 13. Client Type Authorization Flow Server-side Web Application Authorization Code Grant Third-Party Browser-based Client-side Applications Implicit Grant First-Party Clients (browser-based and Native) Resource Owner Password Grant Clients accessing Resources as themselves Client Credentials Grant Native Applications (with a Backend Web Server) Authorization Code Grant or Implicit Grant Native Applications (without a Backend Web Server) A custom flow that looks like Authorization Code Grant or Implicit Grant but gets tricky. Authorization Flows Each of the client profiles needs to be accommodated with an appropriate protocol flow for obtaining authorization from the resource owner for access to their data. The core OAuth 2.0 protocol defines four primary “grant types” used for obtaining authorization.
  • 14. • The resource owner is first redirected by the application to the OAuth authorization server at the API provider. • The authorization server checks to see if the user has an active session. If he / she does, the authorization server prompts her for access to the requested data. If he / she doesn’t, then the user is asked to login with a username and password and then prompts for access. • After she grants access, she is redirected back to the web application and an authorization code is included in the URL as the code query parameter: http://www.example.com/oauth_callback?code=ABC1234 • Because the code is passed as a query parameter, the web browser sends it along to the web server that is acting as the OAuth client. This authorization code is then exchanged for an access token using a server-to-server call from the application to the authorization server. This access token is used by the client to make API calls. • Should be used when: • Long-lived access is required. Supports Refresh Tokens. • The OAuth client is a web application server. • Accountability for API calls is very important and the OAuth token shouldn’t be leaked to the browser, where the user may have access to it. Authorization Code Grant
  • 16. • The Implicit Grant flow used widely for browser-based client-side web applications is very simple. • In this flow, an access token is immediately returned to the application after a user grants the requested authorization. An intermediate authorization code is not required as it is in the server-side Web Application flow. • Should be used when: • Only temporary access to data is required. Does not accommodate Refresh Tokens. • The user is regularly logged into the API provider. • The OAuth client is running in the browser (using JavaScript, Flash, etc.). • The browser is strongly trusted and there is limited concern that the access token will leak to untrusted users or applications. Implicit Grant
  • 18. • The Resource Owner Password Credentials flow allows exchanging the username and password of a user for an access token and, optionally, a refresh token. • This flow has significantly different security properties than the other OAuth flows. The primary difference is that the user’s password is accessible to the application. • This requires strong trust of the application by the user. • The main difference between Password-based apps that have been around in the last two decades and these new OAuth 2.0 specified Password-based apps are that these new ones use Bearer Tokens and not Session Cookies. • Should be used when: • Because the resource owner’s password is exposed to the application, this flow should be used sparingly. • It is recommended only for first-party “official” applications released by the API provider, and not opened up to wider third-party developer communities. Resource Owner Password Grant
  • 20. • Most of the OAuth flows are for handling delegated authorization, when a resource owner grants access to an application to access her data. • However, there are cases when the client itself owns the data and does not need delegated access from a resource owner, or delegated access has already been granted to the application outside of a typical OAuth flow. • The only popular example using this is Facebook AppLogin. • Should be used when: • Imagine a storage API, such as Google Storage or Amazon S3. You’re building an application that has resources (data files, images, etc.) stored externally to your app using one of these APIs. • The application needs to read and update these resources, but acting on behalf of the app itself rather than on behalf of any individual user. • This is a perfect use case for the Client Credentials flow. • The application can ask the OAuth authorization server for an access token directly, without the involvement of any end user. Client Credentials Grant
  • 22. Q & A