Introduction
- There is a strong trend distributed systems with lightweight architectures
- So what are people doing about security in such systems?
Dave Syer, 2012
Twitter: @david_syer
Email: dsyer@vmware.com
(Securing REST-ful Web Services with OAuth2)
Identity and permissions:
Example:
$ curl "https://$username:$password@myhost/resource"
Centralizing account management and permissions:
curlA Client application, often web application, acts on behalf of a User, but with the User's approval
Common examples of Authorization Servers on the internet:
Example command line Client:
$ curl -H "Authorization: Bearer $TOKEN" https://myhost/resource
https://myhost is a Resource ServerTOKEN is a Bearer TokenResource Servers are free to interpret tokens
Example token contents:
Example of implementation (from Cloud Foundry UAA, JWT = signed, base64-encoded, JSON):
{ "client_id":"vmc",
"exp":1346325625,
"scope":["cloud_controller.read","openid","password.write"],
"aud":["openid","cloud_controller","password"],
"user_name":"vcap_tester@vmware.com",
"user_id":"52147673-9d60-4674-a6d9-225b94d7a64e",
"email":"vcap_tester@vmware.com",
"jti":"f724ae9a-7c6f-41f2-9c4a-526cea84e614" }
A client can act in its own right (not on behalf of a user):
$ curl "https://myclient:mysecret@uaa.cloudfoundry.com/oauth/tokens"
-d grant_type=client_credentials -d client_id=myclient
Result:
{
access_token: FUYGKRWFG.jhdfgair7fylzshjg.o98q47tgh.fljgh,
expires_in: 43200,
client_id: myclient,
scope: uaa.admin
}
The Client wants to access a Resource on behalf of the User
A client can act on behalf of a user (e.g. authorization_code grant):
Authorization Server authenticates the User
Client starts the authorization flow and obtain User's approval
Authorization Server issues an authorization code (opaque one-time token)
Client exchanges the authorization code for an access token.
client_id and maybe a
client_secret)client_credentials/authorize)/token)#1 and #4 are covered thoroughly by the spec; #2 and #3 not (for good reasons).
Per the spec they are arbitrary strings. The Authorization Server and the Resource Servers agree on the content and meanings.
Examples:
https://www.googleapis.com/auth/userinfo.profileemail, read_stream, write_streamcloud_controller.read, cloud_controller.write, scim.read,
openidAuthorization Server has to decide whether to grant a token to a given client and user based on the requested scope (if any).
GET /Groups, Get /Users/{id}
{
"id": "73ba999e-fc34-49eb-ac26-dc8be52c1d82",
"meta": {...},
"userName": "marissa",
"groups": [
...
{
"value": "23a71835-c7ce-43ac-b511-c84d3ae8e788",
"display": "uaa.user",
"membershipType": "DIRECT"
}
],
}
The UAA authenticates requests from vmc in a special way:
$ curl https://uaa.cloudfoundry.com/oauth/authorize
-d response_type=token -d client_id=vmc
-d redirect_uri=https:uaa.cloudfoundry.com/redirect/vmc
-d source=credentials
-d username=$username -d password=$password
Result:
302 FOUND
...
Location: https://uaa.cloudfoundry.com/redirect/vmc#access_token=FUYGKRWFG.jhdfgair7fylzshjg.o98q47tgh.fljgh...
/authorize and /token)grant_type=password)
UAA makes some explicit choices where the spec allows it, and also adds some useful features:
resource_id)/userinfo endpoint for remote authentication (SSO)/authorize:
source=credentials - used by vmcsource=login - used by Login Servercode=.../
#