How to access to my own API from my web application securely?

Question

I have APIs. Some of them are limited to access from third party applications by OAuth.

I also have a web application. Users can login and see their private information.

The API is called from the web application too. My question is what is the good way to access the API with security measures.

1. Third party applications -> OAuth

2. My own web application -> ???

My web application uses session id for authentication. I guess that transferring the session id with HTTP header may be good way but I don't have a confidence.

For exmaple...

$ curl -X PUT \
       -H "X-Sample-Application-Id: "My own web application's ID" \
       -H "X-Sample-Session-Token: yeoql2dvn7whpm4tbe61viscv" \

If API receive this request, use session for authentication instead of oauth and identify the user....

Any help will be appreciated.

Thanks,

.. I found similar questions

Questions About Consuming Your Own API with OAuth

---

Update1

Some say JWT(Json Web Token) is good.

https://auth0.com/blog/2014/01/07/angularjs-authentication-with-cookies-vs-token/

http://blog.mitsuruog.info/2014/08/jwtjson-web-tokenwebapicredential.html

---

Update2

I may be able to use OAuth's "Resource Owner Password Credentials"

https://www.ipa.go.jp/security/awareness/vendor/programmingv2/contents/709.html

Or... "Client Credentials grant" looks much better.

Answer 1

I'm going to elaborate a bit on this, because it's a good question, and there is a lot of confusion around it -- so bear with me here.

If the API you are trying to protect is going to exclusively be used by individuals for server-side apps, and not third-party developers, I'd highly, HIGHLY recommend you use HTTP Basic Authentication to secure your API service.

The way this works is super straight forward:

• For your user(s), generate API Key pair(s) that consist of an ID and Secret. API keys are synonymous with username/passwords. Just generate random ID / Secret values using a UUID library.

• When you authenticate against your API service, supply those API credentials in the HTTP Authorization header to identify yourself. Here's how it looks using curl:

  $ curl --user my-api-keyid:my-api-key-secret https://api.myservice.com/blah

What's great about Basic Auth is that:

• It's very simple to implement.
• It's a well defined standard.
• As long as you are making requests over HTTPS, and you don't publicize your API keys, you should be safe.

Now -- if you're building an API service where you want to authenticate users from a variety of environments (not just server side applications), you really need to use the OAuth2 protocol.

This is what it was designed for.

The OAuth2 protocol can authenticate users in a variety of ways -- but as a result, is quite complicated. Adding OAuth to your site can be a challenge, even if you're using popular libraries / etc.

Here's how OAuth works (a quick breakdown):

The Password Grant

The Password flow in OAuth is where you exchange a username/password for an Access Token (usually a JWT). You then use the Access Token in the HTTP Authorization header to identify yourself with your API service.

This is what most people do when building SPAs with Angular / React, as well as mobile apps.

The Client Credentials Grant

The Client Credentials flow is where you exchange an API key (just like basic auth) for an Access Token. You then use the Access Token in the HTTP Authorization header to identify yourself with your API service.

This is what people do when building server side apps with OAuth.

The Implicit Grant

This flow is what you see when you log into some place like Facebook. You click a button, are redirected to some other site to authenticate / accept permissions, and finally you're returned back to the main site with an Acccess Token that you use to identify yourself. This is NOT ideal for API services.

The Authorization Code Grant

This flow is exactly like the implicit flow, except you get back an authorization code that you then EXCHANGE for an Access Token that you use to identify yourself. This is NOT ideal for API services. It's slightly more secure.

If you are planning on going with OAuth because of your use case, I'd highly recommend checking out an authentication provider like Stormpath. They automate a lot of this stuff, and solve a lot of complexities around OAuth.

Otherwise, give Basic Auth a go!