OAuth 2.0 andinternet Standard. Torsten Lodderstedt Deutsche Telekom AG

Transcription

1 OAuth 2.0 andinternet Standard Protocols Torsten Lodderstedt Deutsche Telekom AG

2 Whatshallweaimfor? make OAuth the authorization framework of choice for any internet standard protocol, such as WebDAV, IMAP, SMTP or SIP. Why? Because it is Secure Easy touse Scalable General purpose(andbynomeanslimited to3rd party delegation)

3 OAuth 2.0 Adoption A lot of productive implementations exist Standard protocols using OAuth 2.0 OpenId Connect OpenSocial Open Mobile Alliance RESTful APIs UMA BUT perceptionofoauth seemstobe: bestsuited for protecting deployment-specific APIs Is there anything missing?

4 Life ofa client A Walkthrough

5 Example Access documentson a Website using CURL and Web Browser BEARER authentication scheme

6 (1) discovertheenvironment 1. End-user runs curl with some URL referring to his documents curl 2. Web server answers HTTP/ Authorization Required WWW-Authenticate: BEARER realm=" What snext? How does the client(gets to) know the authorization servers endpoint URLs? How does the client learn the authorization server s capabilities?

7 (1) discovertheenvironment(contd.) Discover the authorization server(options) 1. Resource s HTTP response may directly carry information 2. Application protocol specific discovery 3. Domain-specific discovery protocols 4. Full-fledged, generic discovery protocol Discover the authorization server s capabilities endpoint URLs supported extensions(e.g. revocation or registration) supported grant types

8 (1) discovertheenvironment(contd.) Assumptions: authorization: token: grant types: resource owner password credentials grant types: resource owner password credentials and authorization code

9 What smissing? Discover authorization server

10 (2) Introduceclienttoserver Anonymous client is the only available option currently acceptable for resource owner password credentials (CURL) but what about authorization code or implicit typically used by native and browser apps? Assumingtheusernowtriestoaccessthe documents using a browser, the user consent would look like Some anonymous client is asking for permission to access your files at

11 (2) Introduceclienttoserver(contd.) User must be supported in co-relating applicationusageandauthorizationprocess, e.g. Firefox is asking for permission to access your files at

12 (2) Introduceclienttoserver(contd.) Requireddata: name, URL, Howtopublishthisdata? Someoptions: 1. Dynamic client registration wouldalso allowtosetupclientidandsecret(or other credential) 2. Authorization request parameters 3. comparable to user agent header

13 What smissing? Discover authorization server Publish client meta data

14 (3) requestauthorization GET /authz?response_type=code&client_id=abc& state=xyz&redirect_uri=cust://oauth&scope=??? Host: as.example.com Whatwouldbean appropriatescopevalue? scope= GET or scope= HTTP_GET or scope= WebDAV_GET? Wouldbeconsistentwithtoday sstandardpractice! Most implementationshandle resourcesimplictly, scopesrepresentapi types, permissions, and/or operations Viableoptionforsingleserviceprovidersandenvironmentsoperatinga single service per API/protocol type But what about web servers? (or mail servers, file servers, ) Moreover, itdoesnot allowtocontrolaccessto(sub)setsofresources, such as directories

15 (3) requestauthorization(contd.) What about this? scope= Respective authorization request: GET /authz?response_type=code&client_id=abc& state=xyz&redirect_uri=cust://oauth&scope=https%3a%2f%2 Fwww.example.com%2Fdocuments%2F%23GET Host: as.example.com

16 (3) requestauthorization(contd.) Need tocomeupwitha sustainableconcept ofhowtousescopes(options) 1. Best practices document 2. Design guideline 3. Standard track document defining scope scheme for HTTP-based resources 4.

17 What smissing? Discover authorization server Publish client meta data Scope design guideline

18 (4) Access resources Let sgonow but wait, cantheclientreally trust in Howdoesitknowthisserveristhelegitimate consumer of the access token? Whatifitisa counterfeit resourceserver? Threat prevention through well-known addresses and HTTPS server authentication no longer viable

19 (4) Access resources(contd.) Alternative threat prevention needed (Options) 1. Put actual resource server s URL into token and validate on legitimate server 2. Proof of possession(e.g. MAC) 3. AuthservermightverifyresourceserverURL and, if required, refuse request 4. Authzservermightannouncetotheclientthe valid resource server endpoints 5.

20 What smissing? Discover authorization server Publish client meta data Scope design guideline Countermeasure against counterfeit resource Countermeasure against counterfeit resource servers