0

We have been using SOAP services up until this point and we're creating some new services and using REST. We were using a basic user{Guid}/developer key {Guid} authentication in our SOAP headers.

So we're creating some new services and we're using REST, building in Web API 2.0. So we're trying to decide between keeping a simple user/developer key authentication or using an oAuth/Token authentication. It seems like a lot of newer services all use oAuth. We're not a company with public users logging in, we already have business relationships with our customers before we set them up on our servers so I'm not sure if we need to go that route. Is there a specific reason we should transition to oAuth in our situation?

Also, if I go oAuth, how does the Token persist. I was reading through some examples and it looks like Web API has a lot already built in using OWIN. I see how the token is generated but I don't think I understand the process. How does it persist? Is it in memory, what if I restart my server? We were thinking of storing it in our User record but then we wondered why use it if we're just going to store it alongside user name and password.

Larry Grady
  • 469
  • 7
  • 24

2 Answers2

0

I'm not sure if we need to go that route. Is there a specific reason we should transition to oAuth in our situation?

this should help https://stackoverflow.com/a/7562407/6128276

How does a token persist?

Well in Web API, tokens have an expiry date but you can persist your tokens by using RefreshTokens.

Is it in memory, what if I restart my server?

If you restart your server nothing will happen to the access token because it's never stored on the server, everything you need for authentication is in the access token. Once you send the token to the server it decrypts it using the machine key and restores the user identity (Provided Authorization and Resource server on the same machine).

Community
  • 1
  • 1
Vivek Singh
  • 1,113
  • 10
  • 20
0

If you're APIs can be accessible externally then you should secure them using OAuth (like using the [Authorize] decorator on your end points).

Once you've implemented OAuth you could use the grant type of password and pass similar credentials that you're already passing within your SOAP headers so you're not re-issuing a bunch of credentials to your customers to use the new API endpoints.

On the .Net side once you get your bearer token from the OAuth service you'll need to store that and pass it within the authorization headers every time you make a call to your API.

In C# (after you've gotten your token)

HttpWebRequest req = (HttpWebRequest)WebRequest.Create(<FQDN OF YOUR ENDPOINT>);
req.Method = "GET";
req.Headers["Authorization"] = "Bearer " + <TOKEN YOUR GOT FROM OAUTH>;
try
{
    HttpWebResponse resp = (HttpWebResponse)req.GetResponse();
    if (resp.StatusCode == HttpStatusCode.OK)
    {
        DataContractJsonSerializer ser = new DataContractJsonSerializer(typeof(<RETURN TYPE>));
        <YOUR OBJECT> = (<RETURN TYPE>)ser.ReadObject(resp.GetResponseStream());
    }
}

Sometimes you have to specify the content type, in my case I didn't, but some searching can get that all straightened out for your specific setup.

Charles Paske
  • 76
  • 6