9

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.

Community
  • 1
  • 1
zono
  • 8,366
  • 21
  • 75
  • 113

1 Answers1

10

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!

Jonathan Hall
  • 75,165
  • 16
  • 143
  • 189
rdegges
  • 32,786
  • 20
  • 85
  • 109
  • 1
    I'm so sorry for my late response. Your suggestion is great and I never thought such a excellent idea. Eventually I chose the password grant type because I have to implement our own mobile app too. (we will provide our APIs for 3-rd party mobile app developers) And also, even OAuth is ver y complicated but I can find some libraries. This is also good for me. Using basic auth may be needed custom implementation, not sure but like create table for saving generated key and secret. – zono Mar 04 '16 at 21:05
  • Thanks for the explanation, I have some questions about the password grant. I have build an Authorization server that secure the oauth/token with a Basic Authentication that needs the client_id and the client_secret in order to accept requests. But how I can secure the client_secret? The client is an Angular 2 app. It is necessary to secure the oauth/token uri with Basic Authentication? – Paolo Apr 20 '17 at 15:52