SlideShare uses cookies to improve functionality and performance, and to provide you with relevant advertising. If you continue browsing the site, you agree to the use of cookies on this website. See our User Agreement and Privacy Policy.
SlideShare uses cookies to improve functionality and performance, and to provide you with relevant advertising. If you continue browsing the site, you agree to the use of cookies on this website. See our Privacy Policy and User Agreement for details.
Successfully reported this slideshow.
Activate your 14 day free trial to unlock unlimited reading.
4.
OAuth 2.0
● Open standard for authorization (RFC 6749)
● Provides a method for a third-party to access
resources on behalf of a resource owner
● OAuth 2.0 token are also used to imply
authentication
● OAuth 2.0 process consists of:
1. Obtaining an authorization grant
2. Obtaining an access token
3. Using the access token to make requests
5.
Problems Addressed by OAuth 2.0
● In traditional model, a third-party given access to a
resource owner resources means:
– Third-party must store the resource owner credentials
– Third-party access is not limited in scope
– Third-party access is not limited in time
– The resource owner cannot revoke access to one third-
party only; the only way to revoke access being a change
in credentials
● OAuth2 presents an alternative solution addressing
each of these issues
6.
OAuth 2.0 Roles
● Client
● Resource Owner
● Authorization Server
● Resource Server
7.
OAuth 2.0 Terminology
● Authorization Grant:
– credentials representing the resource owner’s
authorization
– used by the client to obtain an access token
● Access Token:
– credentials used to access protected resources
– represents specific scopes and durations of access
● Refresh Token:
– credentials used to obtain a new access token when
current access token becomes invalid
● Scope:
– determines the specific resources that can be accessed
and the duration of the grant
8.
OAuth 2.0 Clients
● Confidential: can protect their credentials
– web applications
● Public: risk to expose their credentials
– mobile phone apps
– desktop clients
– web-browsers
● Before OAuth2 process can take place, the client
must register to the authorization server
9.
Obtaining Access Token
● There are different ways to obtain an access token:
– Authorization Code
– Implicit
– Resource Owner Password Credentials
– Client Credentials
– Extension Mechanism; e.g. SAML2 Token Insertion
● All communication must be performed through a
secure channel
14.
Implicit Flow (1-3)
1-2: Authorization Request
https://oauthprovider.example.com/oauth/authorize?
response_type=token&client_id= CLIENT_ID&redirect_uri= CALLBACK_URL&scope=re
ad
● response_type= token
● client_id=CLIENT_ID
● redirect_uri=CALLBACK_URL
● scope=read
3: User authorizes request
● User authenticates if not authenticated yet
15.
Implicit Flow (4-6)
4: Browser is redirected to Client’s CALLBACK_URL
https://sample.oauthclient.com/callback #token=ACCESS_TOKEN
● #token=ACCESS_TOKEN
5: Client loads javascript which will extract token from hash
● The web server does not get access token directly
6: Script extracts Access Token from URL’s hash
● Now the script can share it with the client
16.
Access Token
● The access token is a “bearer token”; anyone
presenting it can obtain access:
– The access token is sent through TLS/SSL from the
authorization server to the client
– The access token usually has a short life span and is
renewed through refresh tokens
● A client can query the resource server endpoints to
access resources/information
17.
Accessing Resources
● Once in possession of an access token, the client
presents the token to the resource server
● The resource server validates the token, its scope
and its expiry date
● The validation generally requires interaction or
coordination with the authorization server
GET /protected/resource HTTP/1.1
Host: resource.example.com
Authorization: Bearer ACCESS_TOKEN
18.
Access Token Information
● The specification does not include the
communication between the resource server and
the authorization server
● There are proprietary mechanisms/implementations
– The authorization server has an endpoint which can be
used to get info about the presented access token
GET /openam/oauth2/tokeninfo HTTP/1.1
Host: login.example.com
Authorization: Bearer ACCESS_TOKEN
19.
Bearer Token Recommendations
● Safeguard bearer tokens
● Validate TLS certificate chains
● Always use TLS (https)
● Don’t store bearer tokens in cookies
● Issue short-lived bearer tokens
● Issue scoped bearer tokens
● Don’t pass bearer tokens in URLs
22.
OpenID Connect
● OpenID connect = Identity, Authentication + OAuth2
● OAuth 2.0 is an authorization protocol; when a
client receives an access token it does not know the
identity of the user
● OpenID Connect leverages the OAuth 2.0
handshake to provide Identity assertion through an
ID token
● With OAuth 2.0 the client requests an access token;
with OpenID Connect the client requests an access
token and an ID token
26.
OpenID Connect ID Token
● Signed claim about user identity
● In Standard JSON Web Token (JWT) format
● Client must validate it:
– Signature
– Audience
– Expiry
– Nonce
28.
JSON Web Token
● Compact, URL-safe means of representing
claims to be transferred between two parties
● IETF Standard
– https://tools.ietf.org/html/draft-ietf-oauth-json-web-token-
32
– http://jwt.io/
● Simple Structure:
– Header
– Payload
– Signature
30.
User Information Endpoint
● OpenID Connect specifies it
● Retrieves the user info about the current session
represented by the access token
GET /openam/oauth2/userinfo HTTP/1.1
Host: login.example.com
Authorization: Bearer ACCESS_TOKEN
HTTP/1.1 200 OK
Content-Type: application/json
{
"sub": "248289761001",
"name": "Jane Doe",
"given_name": "Jane",
"family_name": "Doe",
"email": "janedoe@example.com"
}