Home/ Questions/Q 4241200
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-21T03:16:21+00:00

I am building an ASP.NET MVC 3 app that has both a www front-end

  • 0

I am building an ASP.NET MVC 3 app that has both a www front-end (www.example.com) and a developer API (api.example.com). I’d like to make a simple service available to developers where they sign up for a key and make REST calls with it. I’m unclear on a few things:

1) How should I generate and store keys? Is it acceptable to store them in plain text in the database or should I hash and salt them?

2) How do I authorize API calls? I’m guessing I don’t want to do this via ASP.NET Membership for this.

Things like rate-limiting seems straight-forward once I understand those two issues.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    1) That’s really up to you. I’ve seen it done completely differently in different API’s I’ve worked with. Some keys closely resemble GUID’s, others are clearly just random strings, but the important thing is that they’re unique and not easily guessable. As far as how you store it in the database, how much effort you put into protecting your data really depends on the level of sensitivity of users’ accounts. If the nature of the service you’re providing is highly confidential and/or you may end up being audited, then you should take whatever means are necessary to protect the data (using a 1-way hash and salting). My personal philosophy is to keep things as simple as possible until there’s a reason to introduce added complexity, but I’ve worked on sites that used 1-way hashing with salts for authentication.

    2) That depends on who’s going to be using your service. You could use the built-in ASP.NET Forms Authentication Membership Provider, and even integrate it with your public website, but that will limit the usage of your API to developers using a platform that supports cookies on HttpProxies, and will make your API harder to follow. Most REST-ful services I’ve had experience with have used a combination of basic authentication and SSL, which will provide the broadest range of developer support, but will be more complicated to implement on your side. On the server side you’ll have to capture the user credentials out of the HTTP headers and authenticate them against your user database.

    • 0