In today’s world of web APIs, How can you control access to your APIs from malicious attacks? How can you build a trustworthy system? Nowadays you can quickly and easily build Apps – securing those from unauthorized access is really important.
APIs can be secured by using various mechanisms as per the use case provided by Apigee:
- Using OAuth
- Using SAML policies
- Data Masking and hiding
- API Keys
- Content-Based Security
- Key Value Maps
In this blog, we will discuss how we can authenticate with OAuth to deliver a secure and successful customer experience, as it eliminates password sharing between web apps and password storage on mobile devices.
OAuth 2.0
OAuth provides a way to secure and have limited access to your user’s resources for apps. Here’s the definition of OAuth 2.0 from the OAuth 2.0 IETF specification itself:
The OAuth 2.0 authorization framework enables a third-party application to obtain limited access to an HTTP service, either on behalf of a resource owner by orchestrating an approval interaction between the resource owner and the HTTP service, or by allowing the third-party application to obtain access on its own behalf.
The OAuth 2.0 flow
- Resource Owner: The end user, for example, the app wants you to use your data from social media sites, so you are the resource owner who can grant access to your resource.
- Protected Resource: Resource Owner sensitive information.
- Client: It can be a mobile application or a web application. The client can request the resource server to access the user’s protected resource. The resource owner must give the app permission to access the protected resources.
- Access token: A long string of characters that serves as a credential used to access protected resources.
- Authorization grant: Gives the app permission to retrieve an access token on behalf of the end user. OAuth 2.0 defines four specific “grant types”
- Authorization server: Responsible for validating authorization grants and issuing the access tokens that give the app access to the user’s data on the resource server.
- Resource Server: Serves protected resources to the app after OAuth token validation is completed.
OAuth2 comes in: to authenticate you, you need to send an access token in the request, too. The access token tells who you are so that it can be assured that you’re allowed to see the details of the organization.
You can get a token by sending your credentials to the Edge OAuth2 service. The service responds with access and refresh tokens.
OAuth2 flow: The initial request
The following image shows the OAuth2 flow when you access the management API for the first time:
OAuth2 flow: Subsequent requests
On subsequent requests, you will not need to exchange your credentials for a token. Instead, you can just include the access token you already have, as long as it hasn’t expired yet:
OAuth2 flow: When your access token expires
When an access token expires (after 30 minutes), you can use the refresh token to get a new access token:
Conclusion
OAuth 2.0 is the de facto standard for API security. You should now know the basics of this framework and when you should use a certain authorization flow. In the next blog, we will discuss the various grant types that OAuth provides to secure APIs.
Till then Stay Tuned and Happy Blogging!! 🙂
References
