1. Authentication and Authorization
- Authentication (authn): Used to verify whether a user has permission to access the system. If authentication is successful, the user can access the system (but may not necessarily be able to operate on the system’s resources).
- Authorization (authz): Used to verify whether a user has permission to operate on a specific resource. If authorization is successful, the user can perform operations (create, delete, modify, query) on the system’s resources.
2. Authentication
There are four types of HTTP service authentication: Basic, Digest, Bearer, and OAuth.
2.1. Basic
Basic authentication is the simplest authentication method. It encodes in Base64 and places it in the HTTP Authorization Header. When the request reaches the backend service, the backend service parses the Base64 string from the Authorization Header, decodes it to obtain the username and password, and compares it with the values recorded in the database. If they match, authentication is successful.
By using Base64 encoding, passwords can be transmitted in a non-plaintext manner; however, Base64 is not encryption. If an attacker intercepts the Base64 string, they can easily obtain the username and password, making it very insecure. Basic authentication should be used in conjunction with HTTPS to ensure the security of the authentication process.
Basic authentication is natively supported by Gin, using the gin.BasicAuth() middleware directly.
2.2. Digest
Digest authentication is an improved version of Basic authentication. While Basic authentication transmits the username and password in Base64, which is essentially plaintext, Digest authentication uses a “challenge-response” process and hash algorithms to handle passwords, avoiding plaintext transmission.
Although Digest authentication is more secure than Basic authentication, due to compatibility and implementation complexity, it is recommended to use a combination of HTTPS + Basic or Bearer Token in mainstream HTTP service scenarios.
2.3. Bearer
Bearer authentication is a stateless authentication mechanism based on tokens. The client submits authentication information (such as username + password) to the backend service through login. After successful verification, a token is generated and returned to the client. For subsequent requests, the token is carried in the HTTP header in the format: Authorization: Bearer . The server verifies the validity of the token (such as signature, expiration time, etc.), and if valid, allows access to the system.
JWT (JSON Web Token) is a specific implementation of Bearer Token, formatted as Header.Payload.Signature (connected by a dot), consisting of three parts: header, payload, and signature, using Base64 encoding.
Gin does not have built-in Bearer authentication, but it can be easily implemented using third-party JWT middleware or custom middleware. Bearer authentication is a commonly used token-based authentication method for API services, suitable for distributed, stateless, and front-end/back-end separation scenarios.
2.4. OAuth
OAuth authentication (Open Authorization) is an open standard protocol that allows third-party applications to securely access a user’s partial resource access rights on a platform (such as WeChat, GitHub) without obtaining the username and password. Its core logic is to use an authorization token to replace “username and password” for permission verification, achieving a standardized process for “user authorizing third-party applications to access their resources,” while avoiding the leakage of user passwords.
The current mainstream version is OAuth 2.0, which defines clear roles, processes, and token types, providing flexibility and scalability. OAuth has become the de facto standard for “cross-platform authorization” in the internet ecosystem, such as third-party login, third-party application access to platform resources, and internal system authorization (enterprise scenarios).
3. Authorization
Corresponding to “authentication” is “authorization.” There are five common authorization models: ACL (Access Control List), DAC (Discretionary Access Control), MAC (Mandatory Access Control), RBAC (Role-Based Access Control), and ABAC (Attribute-Based Access Control).
Among them, RBAC is the most mainstream and widely used authorization model. It acts as an intermediary bridge between users and permissions through “roles,” enabling batch management of permissions and avoiding direct binding of users to permissions. The core authorization mechanism of K8s is based on RBAC, which is the recommended and default authorization mode in K8s, consistent with the core idea of traditional RBAC but with targeted extensions for container orchestration scenarios.
The RBAC permission model has fixed roles and cannot cope with dynamic and complex permission scenarios (e.g., “only allowing Zhang San to access data in the Beijing area on weekdays from 9:00 to 18:00”). The ABAC permission model is flexible; compared to RBAC, ABAC has finer control over permissions, specifying which attributes of users can perform which operations on which attributes of resources under what constraints.
4. Practice
With the background knowledge of authentication mechanisms and authorization models, how can we implement authentication and authorization logic in a project?
In my API service, I implemented authentication using the gin.BasicAuth() middleware natively supported by Gin, and integrated the Casbin middleware for authorization. Casbin is a cross-language open-source access control framework that supports various authorization models (such as ACL, RBAC, ABAC, etc.) and achieves dynamic permission adjustments through model configuration and policy storage (it does not handle authentication).
Note that authentication and authorization are theoretically two independent security processes, but they may intertwine in actual system design and implementation. The results of authentication often directly affect the scope of authorization, and many authentication credentials may also carry authorization information.