Date post: | 20-Jan-2015 |
Category: |
Technology |
Upload: | paul-madsen |
View: | 2,775 times |
Download: | 0 times |
OAuth – authen+ca+on & authoriza+on framework for REST APIs
Paul Madsen Ping Iden+ty
Authen+ca+on for SOAP
• The SOAP world has long had standards related to authen+ca+on & authoriza+on of web services
• WS-‐Trust defines a protocol by which a SOAP client can obtain a security token(typically a SAML asser+on)
• WS-‐Security s+pulates how to aKach the token (SAML asser+on) to a SOAP request
But …..
1) REST authen+ca+on • REST world has not had comparable standards
• Nothing comparable to WS-‐Security -‐ mish mash of HTTP Basic, HTTP Digest, password, and SSL for message authen+ca+on
• Nothing comparable to WS-‐Trust – consequently client bears burden of managing creden+als & trust
2) Password an+-‐paKern
Site asks YOU for your GOOGLE password so it can access your Google stuff.
Tsk tsk!
• Teaches users to be indiscriminate with their passwords
• Doesn’t support granular permissions, e.g. X can read but not write
• Doesn’t support (easy) revoca+on – to be sure of turning off access users must change password
Importance of revoca+on
WTF is this thing?
I should use that more
This is shiny!!!!!
3) Cloud APIs • Within move towards SaaS – trend towards API access to data/services to supplement/replace browser access
• Salesforce.com expects that within the next year – only 1/3 of access will be via browser
• APIs of PaaS offerings allow the customer to expose its own cloud services
• Clear trend for these APIs is towards REST
Cloud cures everything
4) Na+ve mobile apps
Drivers
Lack of standards
Cloud APIs
Password an+-‐paKern
Na+ve mobile Applica+ons
OAuth
OAuth 2.0
• Defines authoriza+on & authen+ca+on framework for RESTful APIs
• Approaching final standardiza+on in IETF • Applied to delegated authoriza+on – mi+gates password an+-‐paKern -‐ archetypical use case
• Also applicable to many other scenarios – even those with no users
• Notable for its op+miza+ons for mobile
Mobile app IdM architecture
Na+ve vs web apps • Not going to try to predict winner – expect both • Authen+ca+on & authoriza+on should be consistent
across both models, so that
– Users are not confused, eg use different creden+als and/or authen+ca+on ceremony for the two models, even if accessing the same applica+on
– Service Providers aren’t forced to implement duplicate & incompa+ble security frameworks for the two models
Federa+on • Federa+on abstracts away from applica+ons specifics of authen+ca+on & authoriza+on – outsourced to specialized providers
• Complexity hidden by token issuance & valida+on • Federa+on standards define
– Token formats
– How clients obtain tokens – How clients present tokens to applica+on providers
Tokens • Federated authen+ca+on for both web and
na+ve mobile applica+ons is based on exchange and delivery of tokens to the applica+on
• Tokens carry (or point to) security informa+on (like aKributes or authoriza+ons) for user trying to access the applica+on.
• Clients typically exchange creden+als for tokens -‐ easier/safer to share the token across the network rather than the original creden+als
• When token is subsequently presented to an applica+on provider, they serve to authen+cate and/or authorize the request
Federa+on takes different forms
app
data
AKributes for authen+ca+on
Authoriza+on for aKributes
For web apps, tokens carry
For na+ve apps, tokens carry
app
Browser
Tokens for mobile web applica+ons • Federa+on for web applica+ons manifests as SSO from some IdP to the applica+on provider
• SSO especially relevant for mobile
• Tokens aKes+ng to the user’s iden+ty and/or authen+ca+on status delivered through (as redirects) the browser from IdP to the applica+on provider
• Applica+on provider validates token and extracts iden+ty aKributes from within in order to create local session
Tokens for web applica+ons
Iden+ty provider Service provider
Device Browser
Pwd HTML
1. User trades creden+als for a token from IdP
2. Token delivered through the browser to SP
3. SP validates token, and delivers applica+on HTML to browser
Token
SAML OpenID Applica+on
Best prac+ces • Standards
– OpenID 2.0 for consumer scenarios – SAML 2.0 for enterprise & cloud – WS-‐Federa+on for homogeneous MSFT
• IdP Discovery – In consumer space, consider Nascar with email-‐based supplement
– In cloud space, consider email-‐based • Both IdP (portal) and SP (deep-‐linking) ini+ated are relevant
• Mobile browser constraints may recommend ar+fact model in SAML
Tokens for na+ve applica+ons
• Na+ve applica+ons authen+cate to REST APIs by presen+ng a token on the call
• The precursor act of the na+ve applica+on obtaining a token is oeen called ‘authoriza+on’ (par+cularly in those cases when the API fronts user info, eg profile, tweets, etc)
• User authorizes (or consents) to the na+ve applica+on having access to the API (and their data) – the authoriza+on is manifested as the issuance of a token to the na+ve app
• OAuth 2.0 dominant protocol by which a na+ve app obtains the desired authoriza+ons and the corresponding token (and then uses against API)
Mobile authn op+ons
Inline
External browser
Embedded browser • Pwd shared with 3rd party • App owns UI
• Visual trust cues • Can leverage stored pwds
• No need to leave app
• Custom scheme • Enables SSO • Enables strong authn • AS owns UI
Tokens for na+ve applica+ons Service provider
Device
Browser
Applica+on
Token Pwd JSON/XML
1. User trades creden+als for a token 2. Token delivered through the browser
to na+ve applica+on 3. Na+ve applica+on presents token on
API calls 4. Applica+on returns applica+on data
as JSON
OAuth
Applica+on
Best prac+ces • Use the browser to authen+cate the user to the AS,
don’t collect user passwords within na+ve applica+on itself
• A separate browser window preferred to embedded – gives user the visual trust cues trained to look for
• OAuth authoriza+on code grant type is relevant – allows a refresh token to be delivered to the na+ve applica+on (obviates need to con+nually reauthorize)
• Use browser for IdP discovery if doing SSO (rather than within na+ve applica+on itself)
• Na+ve applica+on should register custom scheme on install, to enable subsequent passing of token from browser back to na+ve applica+on
Walk through
• Walk through scenario of an employee using a na+ve app on their phone/tablet to interact with a SaaS provider
• SAML provides – Authen+ca+on of employee to SaaS provider
• OAuth provides – authoriza+on of na+ve app to access SaaS APIs – Issuance of tokens from SaaS to na+ve app
Walk through
SAML
OAuth
OAuth
Load authz page
Load authz page
Load authz page GET /as/authoriza+on.oauth2?client_id=mobileapp&state=abc123&redirect_uri=mobileapp://redirect_here&response_type=code HTTP/1.1
Note -‐ -‐ No client pwd -‐ -‐ custom scheme on redirect URL -‐ -‐ response type of ‘code’
IdP Discovery
IdP Discovery
IdP discovery
SSO Request
SSO request
SSO Request
<samlp:AuthnRequest xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" xmlns:saml="urn:oasis:names:tc:SAML:2.0:asser+on" ID="aaf23196-‐1773-‐2113-‐474a-‐fe114412ab72" Version="2.0" IssueInstant="2004-‐12-‐05T09:21:59Z”>
<saml:Issuer>hKps://sp.example.com/SAML2</saml:Issuer> <samlp:NameIDPolicy AllowCreate="true" Format="urn:oasis:names:tc:SAML:2.0:nameid:format:persistent"/>
</samlp:AuthnRequest>
<form method="post" ac+on="hKps://idp.example.org/SAML2/SSO/POST" > <input type="hidden" name="SAMLRequest" value="request" /> <input type="submit" value="Submit" /> </form>
User authen+ca+on
User authen+ca+on
User authen+ca+on
SSO response
SSO Response
SSO Response <saml:Asser+on> <saml:Issuer>hKps://idp.example.org/SAML2</saml:Issuer>
<ds:Signature xmlns:ds="hKp://www.w3.org/2000/09/xmldsig#">...</ds:Signature>
<saml:Subject> <saml:NameID Format="urn:oasis:names:tc:SAML:2.0:nameid-‐format:persistent"> 3f7b3dcf-‐1674-‐4ecd-‐92c8-‐1544f346baf8 </saml:NameID></saml:Subject>
<saml:AKributeStatement>
<saml:AKribute Name=“email” >
<saml:AKributeValue xsi:type="xs:string">pmadsen@pingiden+ty.com</saml:AKributeValue>
</saml:AKribute>
</saml:AKributeStatement>
</saml:Asser+on>
Response with code
Response with code
Response with code HTTP/1.1 302 Found Loca+on: mobileapp://redirect_here?
state=abc123&
code=wizJmaSTPAf0wqSeB3vmDx2mNSZK6g
Content-‐Length: 0
Trade code for token
Trade code for token
Trade code for token GET /as/token.oauth2?client_id=a&redirect_uri=mobileapp://
redirecthere&grant_type=authoriza+on_code&code=wizJmaSTPAf0wqSeB3vmDx2mNSZK6g HTTP/1.1
Host: as.com
Accept: */*
HTTP/1.1 200 OK Content-‐Type: applica+on/json; charset=UTF-‐8
{"token_type":"Bearer","expires_in":"60","refresh_token":"oQWqwMUIL2ndeMHsWEyFO0GyalvKSvc2QI4YuG82RMGkM","access_token":"lSBbci4Jg8MsjiSqZLBrzEXgd4mKUNhOkyF"}
Client calls API
Client calls API
Client calls API hKps://graph.facebook.com/paul.e.madsen/
friends/?access_token=lSBbci4Jg8MsjiSqZLBrzEXgd4mKUNhOkyF
Verify token
Verify token
Verify token GET /as/token.oauth2?
client_id=b&client_secret=pwd&grant_type=urn:ping:validate&token=lSBbci4Jg8MsjiSqZLBrzEXgd4mKUNhOkyF HTTP/1.1
Host: as.com
Accept: */*
HTTP/1.1 200 OK Content-‐Type: applica+on/json; charset=UTF-‐8
Not OAuth defined
Return Data
Return Data
Return data
HTTP/1.1 200 OK Content-‐Type: applica+on/json; charset=UTF-‐8
Time passes
Refresh token
Refresh token
Refresh token GET /as/token.oauth2?
client_id=a&grant_type=refresh_token&refresh_token=oQWqwMUIL2ndeMHsWEyFO0GyalvKSvc2QI4YuG82RMGkM HTTP/1.1
Host: localhost:9031
Accept: */*
HTTP/1.1 200 OK
Content-‐Type: applica+on/json; charset=UTF-‐8
{"token_type":"Bearer","expires_in":"60","refresh_token":"JZ7Qa4yH5C8E3CikvcZZsd4ZLUgVyYnieXqybAFjObQpz","access_token":"49BPI5LuNM310o7hbB9m9cIzImT5M8gcRjE"}
Thanks
Paul Madsen
@paulmadsen