If you're just joining me at this post, I now have 9 previous blogs that cover APIs in hopes of demystifying developer technology a bit. As traditional infrastructure folks, many of us have graduated into this software defined universe of cloud and have had to learn about APIs in a weirder way than our developer colleagues. As a frame of reference, here are the previous posts (feel free to bookmark all - I've been told folks are liking the subject material and the way I've broken things down):
APIs Aren't Just For Devs Pt. 9 - To REST API or Use GraphQL, That is the Question... (shankuehn.io)
Another aspect of understanding REST APIs is making sense of authentication and authorization. The industry calls these terms AuthN (authentication) and AuthZ (authorization) respectively.
Here's a quick breakdown so you feel more informed in talking this through from an architectural perspective (feel free to skip if you already know):
AuthN (Authentication) - This is the process of verifying an identity of a user or entity to ensure they are who they claim to be. This involves providing credentials like usernames and passwords, biometrics, or other secure means to gain access to a system.
AuthZ (Authorization) - This is the process of determining what actions or resources a verified user or entity is allowed to access or perform. It involves checking the permissions and privileges associated with an authenticated identity to ensure they have the appropriate rights to perform certain actions or access specific resources.
Authentication in the context of using a REST API refers to the process of verifying the identity of a user, application, or system before granting access to the API's resources. It ensures that only authorized parties can interact with the API and perform actions such as retrieving data, submitting data, or performing other operations.
Using a REST architecture, APIs expose endpoints that represent different resources or functionalities. These endpoints are accessible via HTTP methods such as GET, POST, PUT, and DELETE (as I've covered in previous posts - linked above). To prevent unauthorized access and protect sensitive data, authentication mechanisms are implemented on the API endpoint.
There are several common authentication methods used with REST APIs:
API Keys: An API key is a unique identifier that is provided to the client by the API provider. The client includes the API key in the request's headers or query parameters. The server then validates the API key to grant access.
Basic Authentication: In this method, the client sends a request with a username and password encoded in the Authorization header using Base64 encoding. One thing to note is this method is no longer considered secure on its own, as the credentials can be easily intercepted if not transmitted over HTTPS.
Token-based Authentication: This method involves generating a token (often a JSON Web Token or JWT) upon successful login. The token is then included in the headers of subsequent requests. Tokens are signed and may contain information about the user or their roles. This method is more secure than basic authentication, and tokens can have expiration times, reducing the risk of long-term misuse.
OAuth: OAuth is a more complex protocol for authorization, often used for granting third-party applications limited access to a user's resources without exposing their credentials. OAuth involves an authorization server, a resource server, and clients (or applications). It's widely used for scenarios where a user wants to grant a service access to their data without sharing their username and password.
Bearer Tokens: Bearer tokens are a type of token-based authentication where the client includes the token directly in the request headers. The server validates the token and grants access if it's valid.
Multi-factor Authentication (MFA): This adds an extra layer of security by requiring the user to provide additional verification beyond just a password or token. This could involve a code sent to their mobile device, a fingerprint scan, or other methods.
API creators and maintainers need to choose an appropriate authentication method based on the security requirements of the API and the sensitivity of the data it contains or handles. Additionally, using HTTPS (SSL/TLS) is another crucial mechanism to encrypt the communication between a client and server, preventing any nefarious eavesdropping and data tampering during a transmission. Nefarious is one of my favorite words.
Authorization in the context of a REST API endpoint refers to the process of determining whether a user, application, or entity has the necessary permissions to access a specific resource or perform a particular action on that resource. AuthN (see, you can now use these industry terms and feel more "in the know") ensures that only authorized individuals or systems can access and manipulate data or functionalities provided by the API. This is a critical aspect of API security, as it helps protect sensitive information and maintain proper control over API usage.
Here's how authorization typically works with a REST API endpoint:
Authentication: Before authorization can occur, the client (user or application) needs to prove its identity through authentication. Authentication is the process of verifying the provided credentials (such as username and password, API key, token, or certificate, as I covered earlier) to confirm that the client is who it claims to be.
Tokens: This is the most common method for authentication (especially in this cloud based, software defined universe). Tokens are generated by the server upon successful authentication and are sent by the client in subsequent requests to prove its identity without having to re-send credentials with each request.
Authorization Process: Once the client is authenticated, the server proceeds with the authorization process to determine whether the authenticated client has the necessary permissions for the requested action on a specific resource. This is typically done by checking the client's token and comparing it against the predefined access control rules.
Access Control Rules: Access control rules define what actions a particular client or user can perform on which resources. These rules are usually defined based on roles, permissions, and the principle of least privilege. Common roles might include "admin," "user," or "guest," each with different levels of access to various resources.
Authorization Checks: The server performs authorization checks by examining the client's token and the requested resource in the API endpoint. It checks whether the token's associated user or role has the necessary permission to perform the requested action (e.g., GET, POST, PUT, DELETE) on the specific resource.
Response: After the authorization checks, the server sends back a response indicating whether the client is authorized to access the resource. If authorized, the requested action is performed, and the appropriate data is returned. If not authorized, the server returns an error response (such as HTTP 403 Forbidden) with a message indicating lack of permissions.
Ok to recap, authorization is separate from authentication, even though they often go hand in hand. Authentication establishes who the client is, while authorization determines what the authenticated client is allowed to do.
To implement effective authorization for your REST API, your teams should carefully design access control rules, choose appropriate authentication mechanisms, and ensure that sensitive data and operations are properly protected from unauthorized access.
Ok I promise - I'm getting to the end of these posts. I swear! SOON YOU WILL SEE EXAMPLES AND THIS WILL SOLIDIFY ALL KNOWLEDGE! Well...hopefully...
Stay tuned though...if you've hung out this long, there's a few more posts and then I get to move onto...you guessed it...PLATFORM ENGINEERING!
ความคิดเห็น