APIs operate using the web, but like web applications, many API require some sort of authentication or authorization before you can access the valuable resources available within each API path. When you open up your APIs on the web you aren’t just giving away access to your resources to anyone who comes along. API providers employ a number of different authentication mechanisms to ensure only the applications and systems who should have access are actually able to make a successful API call. To help refresh the types of authentication available across the API landscape, while also demonstrating the reach of Postman as an API client, I wanted to take a fresh look at authentication to help my readers understand what is possible.
Depending on the API provider, platform, and the types of resources being made available you will encounter a number of different authentication methods—here are the 11 that Postman supports, reflecting 90% of the APIs you will come across publicly, as well as within the enterprise organization. Refelecting what the API sector employs for authentication of their APIs, as well as what Postman supports as an API client.
- No Authentication – Like the web, these APIs are publicly available and accessible without any authentication. You can just make a request to a specific URL, and you get the response back without needing any credentials or key. This reflects a very small portion of the API economy, but still is an important aspect of the overall authentication discussion, and what is possible.
- API Key – An application programming interface key (API key) is a unique identifier used to authenticate a user, developer, or calling program to an API. However, they are typically used to authenticate a project with the API rather than a human user. Different platforms may implement and use API keys in different ways.
- Bearer token – A Bearer Token is an opaque string, not intended to have any meaning to clients using it. Some servers will issue tokens that are a short string of hexadecimal characters, while others may use structured tokens such as JSON Web Tokens.
- Basic Auth – In the context of an HTTP transaction, basic access authentication is a method for an HTTP user agent to provide a user name and password when making a request. In basic HTTP authentication, a request contains a header field in the form of Authorization: Basic , where credentials is the base64 encoding of id and password joined by a single colon. It is specified in RFC 7617 from 2015, which obsoletes RFC 2617 from 1999.
- Digest Auth – Digest access authentication is one of the agreed-upon methods a web server can use to negotiate credentials, such as username or password, with a user’s web browser. This can be used to confirm the identity of a user before sending sensitive information, such as online banking transaction history. It applies a hash function to the username and password before sending them over the network. In contrast, basic access authentication uses the easily reversible Base64 encoding instead of hashing, making it non-secure unless used in conjunction with TLS.
- OAuth 1.0 – The OAuth protocol enables websites or applications to access Protected Resources from a web service (Service Provider) via an API, without requiring Users to disclose their Service Provider credentials to the Consumers. More generally, OAuth creates a freely-implementable and generic methodology for API authentication.
- OAuth 2.0 – OAuth 2.0 is the industry-standard protocol for authorization. OAuth 2.0 focuses on client developer simplicity while providing specific authorization flows for web applications, desktop applications, mobile phones, and living room devices. This specification and its extensions are being developed within the IETF OAuth Working Group.
- Hawk Authentication – hawk is part of the hapi ecosystem and was designed to work seamlessly with the hapi web framework and its other components (but works great on its own or with other frameworks). If you are using a different web framework and find this module useful, check out hapi – they work even better together.
- AWS Signature – Signature Version 4 is the process to add authentication information to AWS requests sent by HTTP. For security, most requests to AWS must be signed with an access key, which consists of an access key ID and secret access key. These two keys are commonly referred to as your security credentials. For details on how to obtain credentials for your account, see Understanding and Getting Your Security Credentials.
- NLTM authentication – In a Windows network, LAN Manager (NTLM) is a suite of Microsoft security protocols intended to provide authentication, integrity, and confidentiality to users. NTLM is the successor to the authentication protocol in Microsoft LAN Manager (LANMAN), an older Microsoft product. The NTLM protocol suite is implemented in a Security Support Provider, which combines the LAN Manager authentication protocol, NTLMv1, NTLMv2 and NTLM2 Session protocols in a single package. Whether these protocols are used or can be used on a system is governed by Group Policy settings, for which different versions of Windows have different default settings. NTLM passwords are considered weak because they can be brute-forced very easily with modern hardware.
- Akamai EdgeGrid – An OPEN EdgeGrid API Client is the conduit between your application and the Akamai Intelligent Platform, specifically delivered by Akamai to support their platform.
No authentication, API key, and OAuth are the most common authentication mechanisms you will find in place for publicly available APIs, but Postman has worked hard to support as wide of a spectrum of authentication mechanisms by listening to the community and supporting what they need. I always recommend that API providers, especially public API providers standardize the authentication for their APIs, ensuring that the wider API ecosystem reflects this list, but Postman will continue to follow the latest trends and make sure we are always supporting what is most needed by developers—helping reduce friction for them whenever we can.
Hopefully this authentication overview introduces you API authentication in use by API providers and also supported by Postman. It should demonstrate that publishing APIs using the isn’t about freely and publicly making data, content, media, and other resources available on the open web, and that there are a strong set standards in place for securing our digital assets. We see authentication much like consumer and business banking, in that everyone should have a light understanding of how things work. In banking, you don’t have to understand the inner workings of the banking industry, but you should definitely understand who has access to your accounts. API authentication is the same—you don’t have to understand all the technical details, but you need to have a understanding of how your digital resources are access, and who has access to what.
This article originally appeared here.