Introduction to OAuth2.0

Copyright © 2013, Oracle and/or its affiliates. All rights reserved.1
OAuth 2.0 Overview
Oracle Asia Research and Development Center
Alice Liu(lzhmails@gmail.com)

 OAuth 2.0 Overview
 3-Legged OAuth/ 2-Legged Oauth
 OAuth Workflow

 OAuth Terms
– Client is an application accessing an API, can be a web app, app
inside a user agent, or a native app
– Resource Owner is a “user” who can authorize/grant access to API
resources
– Resource Server is the API host
– Authorization Server is the authorization PDP and STS
 OAuth 2.0 is relatively simple
– Get the token
– Use the token to access the protected resource
OAuth 2.0 Overview
OAuth 2.0 Authorization Server

 In the traditional client-server authentication model, the client accesses a protected resource on the server
by authenticating with the server using the resource owner's credentials. In order to provide third-party
applications access to protected resources, the resource owner shares its credentials with the third-
party. This creates several problems and limitations.
 Third-party applications are required to store the resource-owner's credentials for future use, typically a
password in clear-text.
 Servers are required to support password authentication, despite the security weaknesses created by
passwords.
 Third-party applications gain overly broad access to the resource-owner's protected resources, leaving
resource owners without any ability to restrict duration or access to a limited subset of resources.
 Resource owners cannot revoke access to an individual third-party without revoking access to all third-
parties, and must do so by changing their password.
OAuth 2.0 Overview

3-Legged OAuth
1) The resource owner connects to an OAuth Client
enabled service and requests it access resources at
a different site
2) The OAuth Client (requesting site) redirects the user
to the OAuth Authorization Server, which
authenticates the user and presents a consent page.
It then sends authorization code to the OAuth client
3) The OAuth Client uses the authorization code to
retrieve an OAuth Access Token from the OAuth
Authorization Server
4) The OAuth Client presents the Access Token to the
OAuth Resource Server
5) The Resource Server validates the token with the
Authorization Server
6) The Resource Server provides the requested content
to the OAuth Client
OAuth
Client
Resource
Owner/Agent/
Native App
OAuth
Resource
Server
OAuth
Authorizatio
n Server
2
3
6
4
1Requesting
Site Resource
Site

2-Legged OAuth
 The requesting service (OAuth
Client) preregisters with the
OAuth Authorization Server and
receives client credentials
 The requesting service uses its
client credentials to connect to a
resource server
 The Resource server validates
the clients credentials and
provides the requested content
OAuth
Client
OAuth
Resource
Server
OAuth
Authorizati
on Server
2
3
1

• OAuth allows resource owners to delegate resource access rights to
third-parties.
• No sharing of passwords with third-party apps
• Authorize to certain limited resources
• For a limited time
• Can revoke consent given to the third-party apps
• Where as sharing passwords approach with third-party apps
• Trust issues
• Unwanted level of access
• Not able to revoke etc.
OAuth 2.0 Overview

OAuth Workflow
Consumer
(Client)
Service
Provider
(Resource
Server)
User
(Resource
Owner)
Ask for a Token with
OAuth
Responds with un-
Authorized request token
Redirects with
authorized request token
Requests exchange for
access token
Responds with
requested data
Ask for data with access
token
Ask for authorization
of request token
Redirect user to
content Access
page
Log-in and grant
permission

Using OAuth 2.0 Authorization Code Flow

OAuth Actors/What is OAuth 2.0?
Client Application
Resource Owner
Resource Server
OAuth Server
Accesses Resources
Login, Gives consent
Issues Tokens
Accesses Resources Data
Delegates Authorization
(e.g. photoprinting.com) (e.g. photos from “photos.com”)
Authenticates, Authorizes

• Service Provider (Resource Server) the Service Provider controls all aspects of the
OAuth implementation. The Service Provider is the term used to describe the website or web-service where
the restricted resources are located. It can be a photo sharing site where users keep albums, an online
bank service, a micro blogging site, or any other service where ‘user’s private stuff’ is kept. OAuth does not
mandate that the Service Provider will also be the identity provider which means the Service Provider can
use its own usernames and passwords to authenticate users, or use other systems such as OpenID
• User (Resource Owner) the user is why OAuth exists and without users, there is no need for
OAuth. The users have ‘stuff’ they don’t want to make public on the Service Provider, but they do want to
share it with another site. However OAuth can be used with the two-legged scenarios involving clients and
server, without the need of user interaction.
• Consumer (Client) this is a fancy name for an application trying to access the User’s resources.
This can be a website, a desktop program, a mobile device, a set-top box, or anything else connected to the
web.
• Protected Resources the ‘stuff’ OAuth protects and allow access to. This can be data (photos,
documents, contacts etc.), activities (posting blog item, transferring funds) or any URL with a need for
access restrictions.
What is OAuth 2.0?

 Access Token: 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. Tokens represent specific scopes and durations of access, granted by the resource owner, and
enforced by the resource server and authorization server.
 Refresh Token: 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, or to obtain additional access tokens with identical or
narrower scope (access tokens may have a shorter lifetime and fewer permissions than authorized by the
resource owner).
What is OAuth 2.0?

OAuth 2.0 Grant Types
• Authorization Code – usually clients running on web server
• Implicit – clients run directly in the browser like Javascript plugins
• Resource Owner – User Id/password of the user
• Client Credentials – client credentials
• Refresh Token – to refresh/get a new access token
• Assertion Framework
•Client Assertion ・(Authorization) Assertion ・Support multiple formats: JWT and SAML
• Extended Grants
•Depends on server and deployment needs
•E.g. for Oracle to support OAM tokens

Typical 3-legged OAuth flow with Authorization Code
Grant Type
Background
Checker
Client
Resource
Server
Enterprise OAuth
Server
Token-claim registry
Scope registry
Policy store
User consent
orchestration
Get an “Access
token”
Obtain “Authorization
Grant”(User consent)
Use “Access Token” to
access a resource

Questions

References & Terminology
1. OAuth 2.0 Spec (Core/Classic) - http://tools.ietf.org/html/rfc6749
2. OAuth 2.0 Assertion Framework Spec - http://tools.ietf.org/html/draft-ietf-
oauth-assertions-11
3. OAuth 2.0 JWT Assertion Profile Spec - http://tools.ietf.org/html/draft-ietf-
oauth-jwt-bearer-05
4. OAuth 2.0でWebサービスの利用方法はどう変わるか
http://www.atmarkit.co.jp/fsmart/articles/oauth2/01.html
5. http://lzhairs.blogspot.jp/2013/09/2-legged-oauth-3-legged-oauth.html

Introduction to OAuth2.0

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Destaque

Destaque (20)

Semelhante a Introduction to OAuth2.0

Semelhante a Introduction to OAuth2.0 (20)

Último

Último (20)

Introduction to OAuth2.0