Full Stack Security

OAuth/OpenID Connect and JWTconnecting frontend and backend

DPC, Oct 2015

Peter.Varga@thevrg

http://dpc.huDPC Consulting Ltd

Agenda● OAuth 2.0● OpenID Connect● JSON Web Token (JWT)● Demo● Q&A

OAuth 2.0

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 grant2. Obtaining an access token3. Using the access token to make requests

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

OAuth 2.0 Roles● Client● Resource Owner● Authorization Server● Resource Server

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

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

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

Authorization Code Flow

Authorization Code Flow (1-3)1-2: Authorization Requesthttps://oauthprovider.example.com/oauth/authorize?response_type=code&client_id= CLIENT_ID&redirect_uri=CALLBACK_URL&scope=read

● response_type=code● client_id=CLIENT_ID● redirect_uri=CALLBACK_URL● scope=read

3: User authorizes request● User authenticates if not authenticated yet

Authorization Code Flow (4-7)4-5: Browser is redirected to Client’s CALLBACK_URLhttps://sample.oauthclient.com/callback?code= AUTHORIZATION_CODE

● code=AUTHORIZATION_CODE

6: Client requests Access TokenPOST https://oauthprovider.example.com/oauth/tokenContent-Type: application/x-www-form-urlencoded

client_id=CLIENT_ID&client_secret=CLIENT_SECRET&grant_type=authorization_code&code=AUTHORIZATION_CODE &redirect_uri=CALLBACK_URL

7: Client receives Access Token{"access_token":" ACCESS_TOKEN","token_type":"bearer","expires_in":3872,"refresh_token":"REFRESH_TOKEN","scope":"read","uid":,"info":{"name":"Peter Varga","email":"peter.varga@dpc.hu"}}

Implicit Flow

Implicit Flow (1-3)1-2: Authorization Requesthttps://oauthprovider.example.com/oauth/authorize?response_type=token&client_id= CLIENT_ID&redirect_uri=CALLBACK_URL&scope=read

● response_type=token● client_id=CLIENT_ID● redirect_uri=CALLBACK_URL● scope=read

3: User authorizes request● User authenticates if not authenticated yet

Implicit Flow (4-6)4: Browser is redirected to Client’s CALLBACK_URLhttps://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

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

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.1Host: resource.example.comAuthorization: Bearer ACCESS_TOKEN

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.comAuthorization: Bearer ACCESS_TOKEN

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

OpenID Connect

OAuth 2.0 is NOT an Authentication Protocol

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

OpenID Connect Flow

OpenID Connect Flow (1-3)1-2: Authorization Requesthttps://oauthprovider.example.com/oauth/authorize?response_type=code&client_id= CLIENT_ID&redirect_uri=CALLBACK_URL&scope=openid%20profile

● response_type=code● client_id=CLIENT_ID● redirect_uri=CALLBACK_URL● scope=openid%20profile

3: User authorizes request● User authenticates if not authenticated yet

OpenID Connect Flow (4-7)4-5: Browser is redirected to Client’s CALLBACK_URLhttps://sample.oauthclient.com/callback?code= AUTHORIZATION_CODE

● code=AUTHORIZATION_CODE

6: Client requests Access TokenPOST https://www.googleapis.com/oauth2/v3/tokenContent-Type: application/x-www-form-urlencoded

client_id=CLIENT_ID&client_secret=CLIENT_SECRET&grant_type=authorization_code&code=AUTHORIZATION_CODE &redirect_uri=CALLBACK_URL

7: Client receives Access Token{"access_token": "ya29.JgEXH5-koEv0wnizPyikm8qdpRG","token_type": "Bearer","expires_in": 3597," id_token": "eyJhbGciOiJSUzI1NiIsImtpZCI6Ijc0ZWIyNDY1MGE0NzViNDkz.ZGQzZjFiMjU2MmM5MTZmOTA1MzIyOTAifQ.eyJpc3MiOiJhY2NvdW50cy5nb29nbGUuY29tIiwic3Vi"}

OpenID Connect ID Token● Signed claim about user identity● In Standard JSON Web Token (JWT) format● Client must validate it:

– Signature– Audience– Expiry– Nonce

JSON Web Token

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

JSON Web Token (JWT) Structure

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.1Host: login.example.comAuthorization: Bearer ACCESS_TOKEN

HTTP/1.1 200 OKContent-Type: application/json

{ "sub": "248289761001", "name": "Jane Doe", "given_name": "Jane", "family_name": "Doe", "email": "janedoe@example.com"}

Demo

Starting Implicit Flow with OpenID Connect

Processing Tokens Passed by the Authorization Server

Summary● OAuth 2.0● OpenID Connect● JSON Web Token (JWT)● Demo● Q&A

Q & A