APIConnect & Gateways provide out of the box support to integrate with third party OAuth and OpenID Connect providers. This article outlines some of the best practices in such integration, in light of some of the recent attacks on third party providers (TPPs) and theft of TPP issued access tokens.
With all of the
news and intrigue around the recent Facebook Hack, OAuth tokens have been thrusted into the spotlight. As you build out your own OAuth enabled solution, use these best practices to ensure you are in the spotlight for the right reasons.
Background on OAuth and Access Tokens
Third party providers are entities that authenticate the resource owner, obtain his/her authorization for allowing client applications to access his/her resources and upon successful authentication and authorization of the resource owner, generate and issue access tokens to requesting client applications. There are several types of grants that the client can obtain, but at the end of the OAuth authentication flow, the client application obtains an "OAuth Access token" from the OAuth providers. Using this access token, the client application can access the specified resources of the resource owner for the specified scopes and specified duration.
Note that once client applications have the access tokens, they don't need any other secrets/passwords. This also means, any compromise on access tokens will be devastating. For more details on how OAuth and OpenID Connect protocols work, please refer to the standards.
Background on APIConnect & Gateways support for third party providers
APIConnect provides out of the box support for integrating with any third party OAuth Provider at the time of resource access. As part of the setup, the client ids are replicated on both APIConnect and TPP. The client applications obtain the access tokens from TPPs out of band (not thru APIConnect/Gateway). Once they have obtained the access tokens, the tokens can be used to access APIs that are secured using OAuth security. APIConnect, when it receives OAuth access tokens from a client, uses the configuration information to connect with the validation endpoint of the TPP. If TPP approves of the token after validation, APIConnect allows access to the API. If not, it rejects the request. To get OAuth up and running in your environment using APIConnect, refer to this video tutorial on
Securing APIs using OAuth in API Connect – Video Tutorial. For details on specific third party support, refer to this blog on
Using third party OAuth providers to secure APIsRisks on using external third party providers
- Third party provider could be compromised
- In an event where the TPP is compromised, the resource owner authentication and authorization could be spoofed and malicious clients could pretend as legitimate clients to obtain access tokens.
- Third party provider issued access tokens could be stolen
- This is one of the recent attacks on a popular third party social login provider. If access tokens are stolen, all bets are off as access tokens are the keys to the kingdom.
- Third party provider's implementation of OAuth protocol may not be secure enough
- It could be the case that, TPPs have not set a shorter or configurable Time to Live (TTL) on access tokens. Or TPPs may issue refresh access tokens for clients that use implicit grant type which is a big no-no on OAuth protocol.
- Third party providers may not support all aspects of OAuth standard such as revocation of tokens
- When tokens are compromised, or if clients have to log out, an ideal way of handling such tokens is to revoke them to render them unusable. But if revocation of tokens are not supported, then they remain at large even after the transactions are completed.
Recommended approaches for integration with third party providers
Use APIConnect/DataPower native OAuth provider
If you are able to, use the native implementation of APIConnect / DataPower as the OAuth provider. You can set up APIC as an independent provider for your organization and have APIs secured using OAuth referring to APIC/DP as the OAuth provider. This will give you full control over how the OAuth provider is configured, TTL to be set on tokens, validation and revocation of tokens and so forth.
2. Use a combination of third party provider and native provider capabilities
If you must use a TPP for reasons like social login, integration, etc,. then you could use the third party for authentication purposes alone. Once clients obtain access tokens from TPPs, you could use that tokens to issue a JWT type of tokens on DataPower.
This will give you full control on how the clients eventually access the resources protected by APIs and not fully be reliant on the capabilities of the TPP in securing the tokens. If you want to propagate identity, you could also embed the information from the third party provider's access tokens as JWT claims within the JWT token.
3. If at all you must the third party provider exclusively, make sure you follow the below best practices
Do not cache access tokens obtained from TPPs
- For every request, make sure to validate the access tokens with the TPP. Caching tokens might result in stale states and compromise on the security.
Enable revocation on TPPs and ensure that tokens are revoked by resource owner and/or by client apps at logout
Review TPPs implementation of OAuth protocol
- Is TTL on access tokens configurable and small enough, but still matches the needs of your client applications ?
- Are refresh tokens issued ? Are they configurable ?
- Is revocation of tokens supported ?
Note that these pre cautions are only as secure as the TPP itself. If the tokens are compromised/stolen and the TPP is not aware or has not taken any actions, these steps will do nothing to prevent attacks.
Conclusion
Take great care on how you design security around your resources, as there is an ever increasing need to tighten security. You may never want to compromise on security over performance !
PS: I would like to acknowledge Robert Thelen (Product Manager, APIConnect & Gateways) for reviewing this article and providing valuable feedback !