Authentication Design of API Interface

A set of RESTful API interfaces has been developed to facilitate PC and APP calls, and only session authentication is performed. Each call to API will check whether there is a uid, in the current session, that is, to determine whether a user has logged in. This can prevent unlogged-in users from calling the API interface, but there must be something wrong with this design. So I want to use token authentication, which is similar to github token authentication, which carries token authentication when calling API. In this way, the user can be authenticated without the need for the user to log in.

although the idea is very good, there is a problem. My API interface is not only available to other developers, but also to my own website. For example, the home page shows all users. Api is http://api.example.com/users,. I will request http://api.example.com/users with fetch at the front end, and display all user information on the home page after getting the return value. If I use token authentication, then the API address of http://api.example.com/users should also be added with token, but this is used by a website, not by a third-party developer, so whose token is used must not be used by a certain developer. You can only use a public token, but once the public token, is added to the API request on the PC, as long as you open the developer tool, the token will be known to everyone, and it will lose the meaning of authentication.

I have seen the practice of github. His foreground page data reading does not use the api API to obtain data, but directly returns a page, including html and css,. For example, to read my star project, the url requested by github is https://github.com/joyran?pag.. If you use api to get the data, then the https://api.github.com/users/. api API only returns the data, while the address above returns the full page. In this way, even if the user knows the address https://github.com/joyran?pag., it is difficult for users to return the complete page and can only extract the data they want through regular expressions or other methods, which increases the difficulty. This method for me but a bad place is to write two sets of interfaces, one is API only returns data, the other returns the full page, but my foreground is React + Redux development, all data requests are fetch API interface, and then update store to update the page view, if the data returned by fetch is a complete page, I can not update store.

I also looked at the design of Xiazhihu. The revised Zhihu is also developed based on React + Redux. The foreground data is also obtained by requesting API and then updating the store. Zhihu"s API is not authenticated at the time of request and can be used at will. For example, if https://www.zhihu.com/api/v4/. reads the discussion under the front-end topic, API is not certified and everyone can use it.

so the question arises: is Zhihu designed like that because you can browse the discussion under the topic at will on the PC? I don"t need to restrict your API access. After all, you don"t need API to see the discussion under the topic without authentication. But Zhihu can easily make its API, in this way, and because there are no authentication and access restrictions on API, third-party developers can use this API to develop some third-party applications of Zhihu.

my requirement is to share a set of API interfaces with third-party developers and Mobile APP or WeChat Mini Programs. Third-party developers use developer tools on the PC to analyze the API interface. If you want to call it, you must apply for token to access it. Thank you.


look at your requirements. At present, this is what we do in app. All api must apply for token before they can be accessed. For a single client, the token changes every 20 minutes, with one token for each device. If it is app, then directly use the device number, if it is web, then directly generate a random number to store localstorage as the device number to use. In this way, the device corresponds to the token one by one. Token is placed in memcache, to imply some commonly used user data, such as id, account, and so on. The timeout mechanism is provided with memache. After 20 minutes, the client must refresh the token again using refreshToken. At present, we have nearly 1 million app users, and there is no pressure on a single server to manage token.


since all web pages can access data publicly, there is no need for third parties to add authentication


Why not add a service layer? you pc h5 third party is equivalent to the client

Menu