Authentication in RESTful web services

前端 未结 3 945
野的像风
野的像风 2020-12-31 09:21

I am currently creating a website which users can view and modify their widgets. All interation with the widget data stored on my server will be done through RESTful web ser

3条回答
  •  小鲜肉
    小鲜肉 (楼主)
    2020-12-31 10:11

    This is a great question - but I think your solution may need to be a bit more complex than you are thinking.

    In general, the way in which you want to authenticate this kind of scenario is in a 2-stage handshake. The first step is for your application to provide the server a private key (generated by the server, unique to the client application) to authenticate that it is, in fact, a valid client. This is what provides authoritative evidence to your server that the request is coming from software it knows and can trust.

    The second step, then, is that when a user goes to log in to your client application, they provide a username / password combination. This information, along with your application key, should all be sent up to the server via SSL.

    SSL encrypts the data so that a third-party with a packet-sniffer can't read the data in-transit, and the server does the following:

    1. Checks that the application key is valid.
    2. Validates that the username exists, and is associated with the application.
    3. Encrypts the password and tests the encrypted version against the encrypted version in the database, associated with the username.
    4. IF ALL of the above-listed checks pass, the server returns a session ID, which can be put into a client-side cookie - and used to re-authenticate the user on each subsequent request. IF ANY of the tests fail - the server returns a 401: Unauthorized response, or other similar error.

    At this point, the client can utilize the returned session ID without having to continue to re-submit the application key.

    Your Application

    Now, in your case, you may be actually hosting the client/server in the same application and on the same server. In this case - you can generally skip all of the pieces revolving around the private application key - and simply disallow cross-site script requests instead.

    Why? - because the thing you're really protecting against is the following:

    Server A hosts your RESTful API. Client's B, C and D host clients which will rely upon Server A's API. What you don't want is for Client E (not your application - and malicious) to be able to access Server A either by bypassing or stealing the credentials of one of the other Clients.

    If, however, both client and server are hosted in the same place, and therefore have the same URL - i.e. the RESTful API resides at www.yourdomain.com/api and the client resides at www.yourdomain.com/ - you can generally just not allow any AJAX type requests which originate outside of yourdomain.com - and that is your layer of security.

    In this case, the following is all you should need to do to have a reasonable level of security:

    1. Enable SSL for your server.
    2. Only allow requests to /auth/login (or whatever your login POST method is) to come via SSL (in C# this can be done by using the [RequireHttps] attribute on the method or controller).
    3. Reject any AJAX requests which originate outside your own domain.
    4. Use a layer of encryption in your cookie.

    What should your cookie contain?

    Ideally, the cookie should contain 2-way encrypted data that ONLY your server can decrypt. In other words - you might put something like the user's username or user_id inside the cookie - but 2-way encrypt it using Rijndael or another cryptography system - using an encryption password that only your server has access to (I suggest a random string of characters).

    Then - when you receive subsequent requests with the cookie attached, you can simply do the following:

    1. If the cookie exists, attempt to decrypt it using your private password.
    2. If the resulting decrypted data is garbage - throw a 401: Unauthorized response (this is an altered or fake cookie)
    3. If the resulting decrypted data is a username which matches your database - you now know who is making the request - and can filter / serve them data accordingly.

    I hope this helps. :) If not - feel free to post any comments and ask questions, and I'll try to clarify.

提交回复
热议问题