best practices in building an api security ecosystem

Best Practices in Building an API Security EcosystemPrabath Siriwardena, Director of Security, WSO2

Twitter : @prabath

About Me

Director of Security Architecture @ WSO2 Apache Axis PMC member Blogs

- http://blog.facilelogin.com- http://blog.api-security.org

Books- “Enterprise Integration with WSO2 ESB” with PACKT- “Advanced API Security” with Apress - “Mastering Apache Maven” with PACKT

Naked APIs vs. Managed APIs

API Ecosystem

Gateway Pattern - Benefits

• Decouple clients from the actual API implementation

• No point-to-point to connection• Centralized security enforcing• Centralized auditing & monitoring• Version controlling

Forces Driving IT Business Re-design

Pre OAuth Era

Pre OAuth Era

Pre OAuth Era

Pre OAuth Era

Third-party applications are required to store the resource owner's credentials for future use, typically a

password in clear-text.

Need a better approach ?

Servers are required to support password authentication, despite the security weaknesses created

by passwords.

Need a better approach ?

Third-party applications gain overly broad access to the resource owner's protected resources, leaving resource owners without any ability to restrict duration or access

to a limited subset of resources.

Need a better approach ?

Resource owners cannot revoke access to an individual third-party without revoking access to all third-parties,

and must do so by changing their password.

Need a better approach ?

Compromise of any third-party application results in compromise of the end-user's password and all of the

data protected by that password.

Need a better approach ?

Delegation

Pre OAuth Era

OAuth Evolution

OAuth 1.0a

OAuth 1.0a : Three Legged

OAuth 1.0a : Two Legged

OAuth 2.0 : Resource Owner

• An entity capable of granting access to a protected resource.

• When the resource owner is a person, it is referred to as an end-user.

OAuth 2.0 : Resource Server

• The server hosting the protected resources, capable of accepting and responding to protected resource requests using access tokens.

OAuth 2.0 : Client

• An application making protected resource requests on behalf of the resource owner and with its authorization

OAuth 2.0 : Authorization Server

• The server issuing access tokens to the client after successfully authenticating the resource owner and obtaining authorization

OAuth 2.0

OAuth 2.0 : Authorization Grant Types

Authorization Code

Implicit

Resource Owner Password Credentials

Client Credentials

OAuth 2.0 : Authorization Code

OAuth Handshake

Scope

OAuth 2.0

OAuth Handshake

Scope

Scope is defined by the Authorization Server.

Scope indicates what resource client wants access and which actions he wants to perform on that.

The value of the scope parameter is expressed as a list of space-delimited, case sensitive strings.

The strings are defined by the authorization server.

OAuth 2.0 : Authorization Code

Confidential Client Type

Web Application

OAuth Handshake

OAuth 2.0 : Authorization Code

Client Authenticates to AuthZ Server

BasicAuth client_id / client_secret

OAuth Handshake

OAuth 2.0 : Authorization Code

Authorization Grant Request

OAuth Handshake

• response_type : REQUIRED. Value MUST be set to "code".• client_id : REQUIRED. The client identifier.• redirect_uri : OPTIONAL. Where to be redirected by the Authorization Server.• scope : OPTIONAL. The scope of the access request.• state : RECOMMENDED. An opaque value used by the client to maintain state between the

request and callback.

OAuth 2.0 : Authorization Code

Authorization Grant Response

OAuth Handshake

• code: REQUIRED. The authorization code generated by the authorization server• state : REQUIRED if the "state" parameter was present in the client authorization request.

OAuth 2.0 : Authorization Code

Access Token Request

OAuth Handshake

• grant_type : REQUIRED. Value MUST be set to "authorization_code".• code : REQUIRED. The authorization code received from the Authorization Server.• redirect_uri : REQUIRED, if the "redirect_uri" parameter was included in the authorization

OAuth 2.0 : Authorization Code

Access Token Response

OAuth Handshake

• access_token : REQUIRED. The access token issued by the authorization server.• token_type : REQUIRED. The type of the token. Value is case insensitive.• expires_in : RECOMMENDED. The lifetime in seconds of the access token

OAuth 2.0 : Implicit

OAuth Handshake

Scope

OAuth 2.0 : Implicit

Public Client Type

User Agent based Application

OAuth Handshake

OAuth 2.0 : Implicit

Anonymous Clients

OAuth Handshake

OAuth Handshake

Authorization Grant Request

• response_type : REQUIRED. Value MUST be set to ”token".• client_id : REQUIRED. The client identifier.• redirect_uri : OPTIONAL. Where to be redirected by the Authorization Server.• scope : OPTIONAL. The scope of the access request.• state : RECOMMENDED. An opaque value used by the client to maintain state between the

request and callback.

OAuth 2.0 : Implicit

Access Token Response

OAuth Handshake

• access_token : REQUIRED. The access token issued by the authorization server.• token_type : REQUIRED. The type of the token. Value is case insensitive.• expires_in : RECOMMENDED. The lifetime in seconds of the access token• scope : OPTIONAL, if identical to the scope requested by the client, otherwise REQUIRED.• state : REQUIRED if the "state" parameter was present in the client authorization request

OAuth 2.0 : Implicit

OAuth 2.0 : Client Credential

OAuth Handshake

Scope

OAuth 2.0 : Client Credential

Confidential Client Type

OAuth Handshake

OAuth 2.0 : Client Credential

BasicAuth

OAuth Handshake

OAuth Handshake

Authorization Grant Request

Since the client authentication is used as the authorization grant, no additional authorization request is needed.

OAuth 2.0 : Client Credential

OAuth Handshake

Access Token Request

OAuth 2.0 : Client Credential

• grant_type : REQUIRED. Value MUST be set to ”client_credentials".• scope: OPTIONAL. The scope of the access request.

Note : The client needs to pass BasicAuth headers or authenticate to the Authorization Server in other means.

Access Token Response

OAuth Handshake

OAuth 2.0 : Client Credential

• access_token : REQUIRED. The access token issued by the authorization server.• token_type : REQUIRED. The type of the token. Value is case insensitive.• expires_in : RECOMMENDED. The lifetime in seconds of the access token

OAuth 2.0 : Resource Owner Password Credentials

OAuth Handshake

Scope

OAuth 2.0 : Resource Owner Password Credentials

Confidential Client Type

OAuth Handshake

OAuth 2.0 : Resource Owner Password Credentials

BasicAuth

OAuth Handshake

OAuth Handshake

Authorization Grant Request

The method through which the client obtains the resource owner credentials is beyond the scope of this specification. The client

MUST discard the credentials once an access token has been obtained

OAuth 2.0 : Resource Owner Password Credentials

OAuth Handshake

Access Token Request

• grant_type : REQUIRED. Value MUST be set to ”client_credentials".• username : REQUIRED. The resource owner username, encoded as UTF-8.• password : REQUIRED. The resource owner password, encoded as UTF-8.• scope: OPTIONAL. The scope of the access request.

OAuth 2.0 : Resource Owner Password Credentials

Access Token Response

OAuth Handshake

• access_token : REQUIRED. The access token issued by the authorization server.• token_type : REQUIRED. The type of the token. Value is case insensitive.• expires_in : RECOMMENDED. The lifetime in seconds of the access token

OAuth 2.0 : Resource Owner Password Credentials

OAuth 2.0

Runtime

OAuth 2.0

Runtime

Bearer MAC

OAuth 2.0

Runtime

Bearer MAC

Any party in possession of a bearer token (a "bearer") can use it to get access to the associated resources (without demonstrating possession

of a cryptographic key).

Bearer

Request with Bearer

GET /resource/1 HTTP/1.1Host: example.comAuthorization: Bearer “access_token_value”

OAuth 2.0

Runtime

http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-20

OAuth 2.0

Runtime

Bearer MAC

HTTP MAC access authentication scheme

MAC

Request with MAC

GET /resource/1 HTTP/1.1Host: example.com Authorization: MAC id="h480djs93hd8", ts="1336363200”, nonce="274312:dj83hs9s", mac="kDZvddkndxvhGRXZhvuDjEWhGeE="

OAuth 2.0

Runtime

http://tools.ietf.org/html/draft-ietf-oauth-v2-http-mac-01

Decoupling Authorization Server from Resource Server

Decoupling Authorization Server from Resource Server

POST /introspection HTTP/1.1 Accept: application/x-www-form-urlencoded Host: server.example.com Authorization: Basic czZCaGRSa3F0Mzo3RmpmcDBaQnIxS3REUmJuZlZkbUl3

token=X3241Affw.4233-99JXJ&resource_id=…

{ "active": true, "client_id":"s6BhdRkqt3", "scope": "read write dolphin", "sub": "2309fj32kl", "aud": http://example.org/protected-resource/*}

Externalizing Authorization

XACML

OAuth & XACML

A given access token has a scope associated with it and it governs the access token’s capabilities

A user delegates access to his Facebook profile to a third party, under the scope “user_activities”. This provides access to the user's list of activities as the activities’ connection. To achieve fine-grained access control, this can be represented in an XACML policy.

token=gfgew789hkhjkew87 resource_id=GET https://graph.facebook.com/prabathsiriwardena/activities

XACML Request<Request> <Attributes Category="urn:oasis:names:tc:xacml:3.0:attribute-category:oauth-client"> <Attribute AttributeId="urn:oasis:names:tc:xacml:1.0:client:client-id"> <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">32324343434</AttributeValue> </Attribute> <Attributes> <Attributes Category="urn:oasis:names:tc:xacml:3.0:attribute-category:action"> <Attribute AttributeId="urn:oasis:names:tc:xacml:1.0:action:action-id"> <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">GET</AttributeValue> </Attribute> </Attributes> <Attributes Category="urn:oasis:names:tc:xacml:3.0:attribute-category:scope"> <Attribute AttributeId="urn:oasis:names:tc:xacml:1.0:scope:scope-id"> <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">user_activities</AttributeValue> </Attribute> </Attributes> <Attributes Category="urn:oasis:names:tc:xacml:3.0:attribute-category:resource"> <Attribute AttributeId="urn:oasis:names:tc:xacml:1.0:resource:resource-id"> <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string"> https://graph.facebook.com/prabathsiriwardena/activities</AttributeValue> </Attribute> </Attributes></Request>

XACML Policy

<Policy> <Target> <AnyOf> <AllOf> <Match MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal"> <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string"> user_activities</AttributeValue> <AttributeDesignator MustBePresent="false" Category="urn:oasis:names:tc:xacml:3.0:attribute-category:scope" AttributeId="urn:oasis:names:tc:xacml:1.0:scope:scope-id" DataType="http://www.w3.org/2001/XMLSchema#string"></AttributeDesignator> </Match> </AllOf> </AnyOf> </Target> <Rule RuleId="permit_rule" Effect="Permit"> </Rule> <Rule RuleId="deny_rule" Effect="Deny"> </Rule></Policy>

Cross-Domain API Access

Cross-Domain API Access

curl -X POST -u "QlthIzYUOK5DS0BXW8Cy8uFJjKAa:XFfgPmTbMaQ5eScc0rSnAW9ZIgwa” -H "Content-Type: application/x-www-form-urlencoded;charset=UTF-8" -d "grant_type=urn:ietf:params:oauth:grant-type:saml2 bearer&assertion=PHNhbWxwOl...[omitted for brevity]...ZT4" https://localhost:9443/oauth2/token

Auditing / Monitoring

Chained APIs

Centralized Authorization with Distributed Resource Servers

User Managed Access

• PAT (Protection API Token) : Token issued to the Resource Server to access the Protection API (Authorization Server) with the approval of the Resource Owner.

• AAT (Authorization API Token) : Token issued to the Client to access the Authorization API (Authorization Server)..

• RPT (Requesting Party Token) : Token issued to the Client to access the Protected Resource on behalf of the Requesting Party by the Authorization Server.

Contact us !