Recently, I had given a technical talk on OAuth
2.0.
I
am sharing the presentation if anyone else wants to use it.
Definitely
recommend the site for a complete overview http://oauth.net/2/
This
is the gist of the presentation.
What is Oauth?
It
is an Open Specification that helps to Share Secured Resources across
Applications in a trusted manner.
Shared
Resources could be as simple as like Facebook sharing Friends list, likes and
interests OR Flickr sharing photos.
Major roles regarding
OAuth:
Resource owner: An entity capable of
granting access to a protected resource. When the resource owner is a person,
it is referred to as an end- user.
Resource server: The server hosting
the protected resources, capable of accepting and responding to protected
resource requests using access tokens.
Client: An application
making protected resource requests on behalf of the resource owner and with its
authorization. The term client does not imply any particular implementation
characteristics (e.g. whether the application executes on a server, a desktop,
or other devices).
Authorization server:
The
server issuing access tokens to the client after successfully authenticating
the resource owner and obtaining authorization.
Protected
resource: is a resource stored on (or provided by) the server which requires
authentication in order to access it.
Access tokens: are credentials used
to access protected resources. An access token is a string representing an
authorization issued to the client. The string is usually opaque to the client.
Refresh tokens: are credentials used
to obtain access tokens. Refresh tokens are issued to the client by the
authorization server and are used to obtain a new access token when the current
access token becomes invalid or expires
State: Unique code that is
recognized by the application to prevent CSRF.
Grant Type: This specifies what
the current request is passing to get the access token. Typically identifies
the App mode.
Token Type: In 2.0 version it is
‘Bearer’ type
Revoking
access could be either through code or through the IDP provider consoles.
Exploits & Vulnerabilities of
interest:
Cross-site request
forgery (CSRF) -
is
an exploit in which an attacker causes the user-agent of a victim end-user to
follow a malicious URI (e.g. provided to the user-agent as a misleading link,
image, or redirection) to a trusting server (usually established via the
presence of a valid session cookie).
The
client MUST implement CSRF protection for its redirection URI. This is
typically accomplished by requiring any request sent to the redirection URI
endpoint to include a value that binds the request to the user-agent's
authenticated state (e.g. a hash of the session cookie used to authenticate the
user-agent).
A
CSRF attack against the authorization server's authorization endpoint can
result in an attacker obtaining end-user authorization for a malicious client
without involving or alerting the end-user.
Ex:
Blogs kind of feature where users can exploit the changing of the Access Token.
Cross-linking of
emails –
Some
sites uses email as an assertion. It may use the identity provider’s email
assertion to link to the existing sites which could become a vulnerability if
the IDP doesn’t validate the email address. Register to the site using email
and password. Later login to the site using IDP which uses the same email where
you may smartly try and link both these accounts.
Clickjacking –
malicious
site in which it loads the authorization server's authorization endpoint web
page in a transparent iframe overlaid on top of a set of dummy buttons which
are carefully constructed to be placed directly under important buttons on the
authorization page. When an end-user clicks a misleading visible button, the
end-user is actually clicking an invisible button on the authorization page
(such as an "Authorize" button).
For
most newer browsers, avoidance of iframes can be enforced by the authorization
server using the (non-standard) "x-frame-options" header. This header
can have two values, "deny" and "sameorigin", which will
block any framing, or framing by sites with a different origin, respectively.
Invalid Certificates
-
Need
to verify that the SSL/TLS certificate chain validation is done properly.
Caching -
It
is a good practice to use Authorization header in order to prevent any caching
of the data in the browsers or proxies.
Note:
Remember to always use HTTPS/TLS where all the requests to the Protected
Resource / Auth Servers are protected from being sniffed through various tools.
References:
http://www.google.co.in/url?sa=t&rct=j&q=OAuth+2.0+Replay+attacks&source=web&cd=4&ved=0CFEQFjAD&url=http%3A%2F%2Ftrac.tools.ietf.org%2Fwg%2Foauth%2Ftrac%2Fraw-attachment%2Fwiki%2FSecurityConsiderations%2Foauth20_seccons_20101107.pdf&ei=7HwoUM2JBIrqrAeakoG4CA&usg=AFQjCNHT4kW61dLdU7KmJ8CDKr6thS-Jzw
