C# – How to make sure I always have an API token

I am looking to implement a similar approach. The technologies are different, but the concepts are the same.

Basically, I have:

• ASP.NET MVC 4 web application, using OAuth (which I think uses the DotNetOpenAuth API)
• ASP.NET Web API (REST), in same "space" as above, authorization via header token
• Mobile Device Application, authenticates via OAuth

When the Mobile Device Application authenticates via OAuth, I provide a callback to a method in the Web API which checks that the user exists and has access, and returns a generated token.

Subsequent calls by the Mobile Device Application to the Web API sends the token in the header (over SSL) and thus gets authorized or not per call.

In this case we're not persisting the token beyond the current active session, after which the user would have to authenticate again.

OAuth used in this example, but it could be any other authentication mechanism, which provides a token which would then be used for authorization.

This sounds like the same solution that you're looking at and seems to work fine during some initial testing.

Update: the following is a very good reference for this type of thing: WPF Application With Live ID, Facebook, Google, Yahoo!, Open ID

There are many reasons not to use basic authentication scheme to protect Web API services.

In order to use the service, the client needs to keep the password somewhere in clear text to send it along with each request.

The verification of a password should be very slow (to counter brute force attacks), which would hamper scalability of your service. On the other hand, security token validation can be quick (digital signature verification).

OAuth2 does offer solutions for each of your use cases. Your web application can use the code grant, which gives it an access token it can use to talk to your API.

Your web application will redirect the user's browser to the authorization server. It will prompt the user for credentials (or smart card, or two-factor auth code) and return a code to the browser, which the client (your web application) can use to get an access token from the authorization server.

Your application will also get back a refresh token with which it can get a new access token if the current token expires.

Your CLI application can use the resource owner credentials grant. You will prompt the user for credentials and submit them to the authorization server to acquire an access and refresh token. Once your CLI application has the token, you can discard the user's password in memory.

Both clients (web app and command-line client) need to be registered up front with the authorization server.

Your authorization server may well talk to a LDAP/directory service (identity provider or IdP) to do the actual authentication.

Your web API service only needs to verify the incoming JWT token and establish what the user is allowed to do (authorization).

If you are the victim of a man-in-the-middle attack and you lose your access token, the attacker only has a limited time (token lifetime) to use it. A password is typically valid for much longer. Refresh tokens can be revoked in case they get lost.