OAuth 2.0 Workshop. On how native (mobile) devices can use OAuth protected resources

OAuth 2.0 Workshop

On how native (mobile) devices can use OAuth protected resources

GET /people/@me

● François Kooman _{<[email protected]>} ● SURFnet, Middleware Services

● Technical Product Manager SURFconext ● Working on OAuth and IAM, VOOT, ...

Applications

● Is a website an application?

● Is a “launcher” on your phone that uses an

embedded web browser an application?

● A website becomes an application when it has

both read and write (RWW) support, i.e.: modifies the server state

Authentication & Authorization

Authentication

Making sure you know who you are dealing with

Authorization

Figuring out what the authenticated

application or user is allowed to do

OAuth

● Who is not familiar with the concepts of

What is OAuth?

● Securely allow third parties to access your

Why OAuth?

● Do not give away your password to service

providers, only your (temporary) consent;

● Revoke your consent at any time;

● Limit (“scope”) the access to resources, not

OAuth 1.0a

● OAuth 1.0a for server to server data exchange

OAuth 2

● OAuth 2 for server to server and client

(application) to server data exchange

Terminology

OAuth 1.0a Consumer Service Provider User Request Token Access Token

2 Profiles (2 legged, 3 legged)

OAuth 2 Client Authorization Server Resource Server Resource Owner Authorization Code Access Token 3 Client Profiles

OAuth 2

● Like OAuth 1.0a, but

– More consistent terminology

– New profiles to support different application types – No signatures in “core” protocol

– (Relatively) simple clients – Mandates TLS

OAuth 2 – Client Profiles

● Web application

– These are the “traditional” applications running on a web server

– Client credentials and access tokens are not exposed to the user (resource owner)

– “Confidential” client

OAuth 2 – Client Profiles

● User-agent-based application – Application that runs in the browser

– Access tokens easily accessible by user (resource

owner)

– Only talks to (REST) APIs exposed by a server

– “Public” client

OAuth 2 – Client Profiles

● Native application

– Installed on a device owned by the user (resource

owner)

– It is assumed the user (resource owner) can get to (i.e.: extract) access tokens and refresh tokens

– “Public” client

– Possible with OAuth 1.0a (and actually used) with a “hack” by storing a secret in application binary (not meant as a security feature...)

How does it work?

GET /authorize?response_type=token&client_id=s6BhdRkqt3&state=xyz &redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb HTTP/1.1

Host: server.example.com

“User-agent-based Application” profile

GET /authorize?response_type=code&client_id=s6BhdRkqt3&state=xyz &redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb HTTP/1.1

Host: server.example.com

How does it work?

HTTP/1.1 302 Found

Location: http://example.com/cb#access_token=2YotnFZFEjr1zCsicMWpAA &state=xyz&token_type=example&expires_in=3600

“User-agent-based Application” profile

HTTP/1.1 302 Found

Location: https://client.example.com/cb?code=SplxlOBeZQQYbYS6WxSbIA &state=xyz

User-agent-based Application

● Extract access token from

Web Application & Native

Application

● Exchange _{authorization_code} for

access_token using backchannel

● Native application does not use the

Authorization header (public client)

POST /token HTTP/1.1

Host: server.example.com

Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW

Content-Type: application/x-www-form-urlencoded;charset=UTF-8

grant_type=authorization_code&code=SplxlOBeZQQYbYS6WxSbIA &redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb

Web Application & Native

Application

HTTP/1.1 200 OK Content-Type: application/json;charset=UTF-8 Cache-Control: no-store Pragma: no-cache { "access_token":"2YotnFZFEjr1zCsicMWpAA", "token_type":"example", "expires_in":3600, "refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA", "example_parameter":"example_value" }

Web Application & Native

Application

$ curl -v -H "Authorization: Bearer 2YotnFZFEjr1zCsicMWpAA" http://www.example.org/resource

Native Applications

● Getting creative with the _{redirect_uri} ● Mobile: _{myscheme://callback?}

code=abcd&response_type=code

● Desktop:

http://localhost:1188/app/callback.html? code=abcd&response_type=code

● Use backchannel HTTP request for _code →

OAuth – Benefits

● Separation of authentication and authorization ● OAuth can work with any authentication

mechanism (SAML, plain username and password, OpenID, BrowserID, ...)

● Exposing the (REST) API of your service will

make it easy for (native) application

developers to create an application in a secure way

Architecture

● What data do you want to make available?

– Do standards for exchanging this kind of data already

exist?

– Does the data need to be restricted, or is it “open data”?

● Do you need read-only or read-write support? ● Which client types do you want to support? ● Authentication types?

– SAML

– username and password – LDAP/AD

PageKite

● The fast, reliable way to make localhost part of

the Web.

PageKite makes local websites or SSH

servers publicly accessible in mere seconds, and works with any computer and any Internet connection.

Demo

● The development platform to work with – Client Registration

– Revoke authorization – Some demo clients

Goal

● Non-developers: think about what data to

make available for app developers, security requirements, privacy issues, ...

● Developers: Create a mobile application that

uses the OAuth 2.0 protected resources of the demo environment

Workshop OAuth 2.0 Environment

● OAuth 2.0 playground:

– https://frko.surfnetlabs.nl/workshop/

● You can also run it yourself on your own

laptop, maybe together with PageKite:

– https://github.com/fkooman/oauth-install-all ● Mobile OAuth 2.0 client demo application:

– https://github.com/OpenConextApps/ios-oauth-app