基于令牌的REST API身份验证

Question

I have a mobile app backed up by a lightweight Node.js API. I've recently started exploring integrating a third-party API service that uses token-based authentication. This API is designed to be called exclusively from my server-side Node.js code since calling it directly from my mobile app would expose my sensitive username/password info. Other similar APIs that can only be called server-side (Stripe, for instance) have required authentication with a secret key that is passed in with every request. This approach makes more sense to me since you don't really think of a server "logging in" to another API.

So, here are my questions about accessing a token-based API:

1. What is the best approach to making calls to this API? The token has a lifetime of 1 hour. Should I 1) persist the token in a database and, for each request, pull the token from the database, check that it is still valid then make the request to the third-party API? Or, 2) request a new token every time I need to make a request to the API?

2. What is the benefit of using token based authentication? Since there isn't a concept of logging in and no state needs to be maintained between requests, wouldn't it be easier to use a simple secret key with basic auth?

Answer 1

I'm going to start with #2:

What is the benefit of using token based authentication? Since there isn't a concept of logging in and no state needs to be maintained between requests, wouldn't it be easier to use a simple secret key with basic auth?

A basic auth username and password:

1. Is also a token.
2. Does not actually 'log you in'. It's stateless in the same way, because the username and password get passed with every request.

So the difference between the token you're describing and a password really in this case is about the lifetime of the token. It sounds like you probably actually have 2 tokens. One to do requests (access token) and another to request new access tokens if they expired (refresh token).

Why do this? One idea is that the refresh token is the most dangerous one, because if an access token leaks somehow, it will only be valid for a limited amount of time. By separating these you're basically decreasing the number of potential attack vectors. In a world where everything is secure, this might make no real difference, but we don't live in this world.

Access tokens can leak into logs, or accidentally get exposed through other means. The chance of a refresh token to be exposed is just lower.

Some API's also turn the access token in some signed json payload (jwt), so they don't need to check their data-stores for validity. These services might expire refresh tokens in case of security changes (new password, intrusion detection) but not expire the access token.

But yea it's a bit of a hairy subject. There's no clear attack vector that gets prevented by creating two tokens, but it's defense in depth.

Answer 2

Since question 2 is answered, i would start with question 1

For token based authentication, as you mentioned, for each and every request you can intercept the actual request and verify the token and if the token is valid you can allow the request to access your api. Recently, there is a new standard called JWT Json web tokens. Here is the description about JWT

JSON Web Tokens are an open, industry standard RFC 7519method for representing claims securely between two parties.

JWT.IO allows you to decode, verify and generate JWT.

Using JWT, you can save a DB call on each request. The client is expected to send this token on each request (usually in a http header). On the server, intercept the request take the token and verify the token against a private key and authenticate the user. The token can be generated based on "claims". A claim, for example, can be client ip address or user agent or anything that you think is sensible. I strongly suggest you to use the JWT standard for your token based authentication of the API

Now question 2

Yes Http is meant to be stateless protocol. Especially when you use REST based APIs , they have to be stateless and session less. So a basic authentication would be enough. However, you may have to make a db call to verify the base64 encoded username and password sent by the client. The advantage of JWT token is you can avoid this additional DB call and is much secured than just basic auth