2.10 object-oriented analysis and design method development interface authentication function
2.10.1 Requirements Analysis
Demand proposed:
"In order to ensure the security interface calls, we hope to achieve a design interface calls the authentication function, only after certification of the system to call our interface, no certified system call interface we will be rejected. I want to come to you in charge of the development tasks, for on-line as soon as possible. "
Based on the analysis of the first round: do authentication through a user name plus password .
Each caller to allow access to our services, a distributed application name (or called the application ID, AppID) and a corresponding password (or called secret key). When the caller requested each interface, carries its own AppID and password. Micro service after receiving the call request interface, will parse out the AppID and password, to compare the service at the micro end of the AppID and password with storage. If they are consistent, indicating that the authentication is successful, the call request interface is allowed; otherwise, it refused the request interface calls.
The second round of analysis and optimization: clear text passwords is not secure . With encryption algorithm (such as SHA), then encrypts the password, and then passed to the micro-server authentication is not safe, because the password and AppID after the encryption, authentication system still can not be (or hackers) intercepted unauthenticated the system can carry and the corresponding password AppID after the encryption, disguised as a certified system to access our interface. ** This is a typical "replay attack" **.
token verification : The caller requested URL with AppID, password spliced together the interface, and then encrypted to generate a token. The appid together and pass token server, the server appid removed from the database according to the password generated by the same token are encrypted with incoming client authentication token do comparison, it unanimously rejected inconsistent.
graph TB subgraph Client terminal A (. 1 generates a token: SHA - http // ip:? port / user id = 123 & appid = abc & pwd = pwd123). B (2 generates a new url: http // ip: port / user id? = 123 & appid = abc & token = xxx) a -..> B end subgraph Server terminal C (3 parse the URL \ AppID \ token) D (4 taken AppID corresponding password from the database) E (5 generates a server-side token_s). F1 (. 6 allows access) F2 (6 denied access.) B - end access Server -> CC -> DD -> EE --token equal token_s -> F1 E --token not equal token_s-- > F2 end