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([email protected])


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.



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

1

Requesting

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 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

http://tools.ietf.org/html/rfc6749

http://tools.ietf.org/html/draft-ietf-oauth-assertions-11









http://tools.ietf.org/html/draft-ietf-oauth-jwt-bearer-05











http://www.atmarkit.co.jp/fsmart/articles/oauth2/01.html

http://lzhairs.blogspot.jp/2013/09/2-legged-oauth-3-legged-oauth.html











introduction to oauth2.0

Education