Loading presentation...

Present Remotely

Send the link below via email or IM

Copy

Present to your audience

Start remote presentation

  • Invited audience members will follow you as you navigate and present
  • People invited to a presentation do not need a Prezi account
  • This link expires 10 minutes after you close the presentation
  • A maximum of 30 users can follow your presentation
  • Learn more about this feature in our knowledge base article

Do you really want to delete this prezi?

Neither you, nor the coeditors you shared it with will be able to recover it again.

DeleteCancel

Make your likes visible on Facebook?

Connect your Facebook account to Prezi and let your likes appear on your timeline.
You can change this under Settings & Account at any time.

No, thanks

OAuth 2.0

SecAppDev 2013
by

Stijn Van den Enden

on 26 January 2014

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of OAuth 2.0

Flows
Server Side
Web Application Flow
Client-Side Web Application Flow
aka Authorization Code Flow
1
Use Case
2
Application
User
Resource Provider
wants to grant access to application to access resource
Valet Key
Delegated Authorization
for Web Applications

OAuth Timeline
Start of interest group
Oct.
2007
OAuth Core 1.0
Final Draft
OAuth 1.0 becomes
RFC 5849.
April
2010
Oct.
2012
2007
Finalization of OAuth 2.0 (RFC 6749)
User indicates that she has the intention to allow the application to access a resource at the provider
Redirect
https://<authserver>/path?clientid=98AZ&redirect_uri=https://<application>/callback&scope=some_urn&response_type=code&state=74ZWA
identification of the application
location the user should return to after approval.
data your application wants to access
(space-delimited strings)
e.g. https://www.googleapis.com/auth/tasks
code indicates an authorization code will be returned to the client
a unique value used by the application to prevent cross-site request forgery attacks
unguessable, kept secret in the client, and verifiable by the server
1. Authenticate User and validate request
2. Request user for authorization.
About us
Stijn Van den Enden
s.vandenenden@aca-it.be
@stieno

Jan Van den Bergh
j.vandenbergh@aca-it.be
@janvdbergh

SAML
OpenID
OAuth 1.0
Comparison with
other protocols
OAuth 2.0
Authentication via assertions.
Complex, strict protocol.
XML + Digital signatures
Based on mutual trust.
Authentication via URLs
Authorization
Lightweight protocol.
Extensions to exchange attributes.
Discovery, instead of trust.
Lightweight protocol
Separate process to build
the relationship.
Bearer tokens
(instead of cryptographic proof)
Implementations differ.
Implementations differ.
Good interoperability.
Supported versions
References
OAuth 2.0 Specification
http://tools.ietf.org/html/rfc6749
3
Security Properties
Implementation
OAuth will be there to stay.
Interesting trade-off
between security
and user-friendliness.
Libraries are
your friends.
Conclusions
Learn to live with it!
Watch out for inconsistencies
between providers.
Well-known security mechanisms.
Bearer tokens vs. cryptography.
Don't reinvent the wheel.
OAuth 2.0 Threat Model and Security Considerations
http://tools.ietf.org/html/draft-ietf-oauth-v2-threatmodel-06
Ryan Boyd - Getting Started with OAuth 2 (O'Reilly)
http://shop.oreilly.com/product/0636920021810.do
Resource Owner
Password Flow
1
Use Case
2
Application
User
Resource Provider
Wants to grant access to application to access resource
Has a high-level of the trust in the client application.
User indicates that she has the intention to allow the application to access a resource at the provider.
User enters her username and password into the application
3
Security Properties
Implementation
Client Credentials
Flow
1
Use Case
2
3
Security Properties
Implementation
= Two-legged flow (OAuth 1)
Authorization Server
Resource Server
Resource Owner
1..n
Redirect
https://<application>/callback?error=<error_type>&state=74ZWA[&error_description=<description>][&error_uri=<uri>]
invalid_request
the request is missing a required parameter, includes an invalid parameter value, includes a parameter more than once, or is otherwise malformed.
unauthorized_client
The client is not authorized to request an authorization code using this method.
access_denied
The resource owner or authorization server denied the request.
unsupported_response_type
The authorization server does not support obtaining an
authorization code using this method.
invalid_scope
The requested scope is invalid, unknown, or malformed.
server_error
The authorization server encountered an unexpected condition that prevented it from fulfilling the request.
temporarily_unavailable
The authorization server is currently unable to handle
the request due to a temporary overloading or maintenance of the server.
A human-readable ASCII text providing additional information, used to assist the client developer in understanding the error that occurred.
A URI identifying a human-readable web page with information about the error, used to provide the client developer with additional information about the error.
Same value as the state send in the initial request
Redirect
https://<application>/callback?code=<authorization_code>&state=74ZWA
Indication the user has approved the request
Value of previous passed state parameter
https://<application>/callback?code=<authorization_code>&state=74ZWA
Indication the user has approved the request
Value of previous passed state parameter
POST
code=<authorization_code>
redirect_uri=<redirect_uri>
grant_type=authorization_code
username: client_id
password: client_secret
Authorization: Basic MDAwMDA..
HTTP Header
indication we want to exchange code for an access token
location registered and used in initial request
authorization code passed to the application
{
'access_token' : "<access_token>",
'token_type' : "Bearer",
'expires_in' : 3600,
'refresh_token' : "<refresh_token>"
}
remaining lifetime of the token
token than can be used to acquire new access token after expiration
type of the access token issued
token to be used to authorize requests
HTTP-VERB
Authorization: Bearer <access_token>
HTTP Header
API-Call
Validate validity of the <access_token>
Validate validity of the <access_token>
4xx
WWW-Authenticate: Bearer realm="<>",
error="<error_code>",
error_description="<description>"
HTTP Header
Not Mandated in Spec
if error code is returned the parameter should be called error
{
'error' : {
'type': "OAuthException",
'message': "Error Validating Access Token"
}
}
{
'error': {
'errors': [
{
'domain' : "global",
'reason': "authError",
'message': "Invalid Credentials",
'locationType': "header",
'location': "Authorization"
}
]
}
}
POST
refresh_token=<refresh_token>
grant_type=refresh_token
username: client_id
password: client_secret
Authorization: Basic MDAwMDA..
HTTP Header
indication we want to exchange code for an access token
the previously issued refresh_token
{
'access_token' : "<access_token>",
'token_type' : "Bearer",
'expires_in' : 3600,
'refresh_token' : "<refresh_token>"
}
remaining lifetime of the token
token than can be used to acquire new access token after expiration
type of the access token issued
token to be used to authorize requests
access token is never sent through the browser
access tokens are to be short lived
resource owner can directly attribute the request to the application developer
proper usage of the state parameter prevents CSRF attacks
refresh token are long lived and must be properly stored as they provide an interesting target for attacks
1
Use Case
2
User
Resource Provider
wants to access resource
GET
https://<authserver>/path?clientid=98AZ&redirect_uri=https://<application>/callback&scope=some_urn&response_type=token&state=<state_id>
identification of the application
location the user should return to after approval.
data your application wants to access
(space -delimited strings)
e.g. https://www.googleapis.com/auth/tasks
code indicates we're requesting an access token
1. Authenticate User and validate request
2. Request user for authorization.
3
Security Properties
Implementation
Authorization Server
Resource Server
Resource Owner
Redirect
https://<application>/callback?error=<error_type>&state=74ZWA[&error_description=<description>][&error_uri=<uri>]
invalid_request
the request is missing a required parameter, includes an invalid parameter value, includes a parameter more than once, or is otherwise malformed.
unauthorized_client
The client is not authorized to request an authorization code using this method.
access_denied
The resource owner or authorization server denied the request.
unsupported_response_type
The authorization server does not support obtaining an
authorization code using this method.
invalid_scope
The requested scope is invalid, unknown, or malformed.
server_error
The authorization server encountered an unexpected condition that prevented it from fulfilling the request.
temporarily_unavailable
The authorization server is currently unable to handle
the request due to a temporary overloading or maintenance of the server.
A human-readable ASCII text providing additional information, used to assist the client developer in understanding the error that occurred.
A URI identifying a human-readable web page with information about the error, used to provide the client developer with additional information about the error.
Same value as the state send in the initial request
Redirect
https://<application>/callback#access_token=<access_token>&expires_in=<TTL>&token_type=Bearer&state=<state>
Indication the user has approved the request
Value of previous passed state parameter
HTTP-VERB
Authorization: Bearer <access_token>
HTTP Header
API-Call
Validate validity of the <access_token>
Validate validity of the <access_token>
4xx
WWW-Authenticate: Bearer realm="<>",
error="<error_code>",
error_description="<description>"
HTTP Header
Not Mandated in Spec
if error code is returned the parameter should be called error
{
'error' : {
'type': "OAuthException",
'message': "Error Validating Access Token"
}
}
{
'error': {
'errors': [
{
'domain' : "global",
'reason': "authError",
'message': "Invalid Credentials",
'locationType': "header",
'location': "Authorization"
}
]
}
}
User credentials never seen in the browser
access tokens are to be short lived, ensuring the impact of leakage is limited.
proper usage of the state parameter limits CSRF attacks
less accountability; there is no difference between the resource owner doing the call of a third party application
time to live of the access token in seconds
request new access_token
aka Implicit Grant Flow
Native Application Support
+
OAuth
Why?
Access your own API
Access API from other providers
A
B
Great fit for a REST-based HTTP API
Single Interface for users to log in into the application (source independent, and high trust)
Possibility to limit the scope of the authorization is a plus
Please
don't train your user to enter passwords in apps
Supports the provider's specific authentication settings (e.g. SAML, 2-Factor Authentication, ...)
At least we not asking users to enter credentials of third party apps and are able to limit the scope
Trust
Flows?
Credentials are never sent to the resource server.
Access tokens are short lived, ensuring the impact of leakage is limited.
How?
± client-side implicit flow
± server side application flow
Resource Provider
redirect_uri: myapp://oauth/callback
native application flow
client_secret embedded, so not to be considered secret
not all resource providers support custom URI scheme's
no guarantee that the URI scheme is unique on the device
redirect_uri: urn:ietf:wg:oauth:2.0:oob
code returned as window title
Application
Backend
short-lived access =
long-lived offline access =
Embedded WebViews
Native Browser
Native Library/Platform Support
can be controlled by the native application, well integrated
do not provide any trust indicators (TLS, certificate information,...)
separate cookie store
access to the build in cookie store
typical security indicators are available
no way to control the history of the native browser
requires native callback mechanism
AccountManager.getAuthToken()
SDK delegates to platforms native capabilities
Authorization Server
Resource Server
POST
Authorization: Basic MDAwMDA...

grant_type=password
scope=<URN>
username=<user name>
password=<user password>
HTTP Header
Client id=
Client secret=
{
"access_token":"<access_token>",
"token_type":"Bearer",
"expires_in":3600
}
HTTP 200
HTTP-VERB
Authorization: Bearer <access_token>
HTTP Header
API-Call
User credentials are known to the client application. Client application can do everything it wants.
Access tokens are used to limit exposure of the password.
POST
grant_type=client_credentials
client_id=<Client ID>
client_secret=<Client Secret>
HTTP Header
Application
Resource Provider
Wants to access resources on its own behalf.
Authorization Server
Resource Server
OpenID Connect
Adds OpenID functionality to OAuth.
Step 1
Step 2
Step 3
Get an id_token.
Regular OAuth 2.0 Flow, with
response_type
: include id_token.
scope
: openid (optional: profile, email, address).
nonce
: against replay attacks.
Contact the Check ID endpoint
to verify the id_token.
Response contains:
user id
: unique user identifier.
nonce
: same nonce as before.
aud
: your client_id
Contact the UserInfo endpoint
to get more information about the user.
dag
4xx
WWW-Authenticate: Bearer realm="<>",
error="<error_code>",
error_description="<description>"
HTTP Header
Not Mandated in Spec
if error code is returned the parameter should be called error
{
"access_token":"<access_token>",
"token_type":"Bearer",
"expires_in":3600
}
HTTP 200
4xx
WWW-Authenticate: Bearer realm="<>",
error="<error_code>",
error_description="<description>"
HTTP Header
Not Mandated in Spec
if error code is returned the parameter should be called error
HTTP-VERB
Authorization: Bearer <access_token>
HTTP Header
API-Call
Java
Client: Apache Oltu (was Amber), Google OAuth Client Library.
Server: Spring Security. Jersey
Dali Core Social http://java.net/projects/dalicore
Node.js
Passport.
ObjectiveC
https://code.google.com/p/gtm-oauth/
https://github.com/lukeredpath/LROAuth2Client
javascript
https://github.com/andreassolberg/jso
...
Full transcript