Security concerning API calls from single page application

Not applicable

I ask about the security of API call using OAuth access token from single page application (SPA).

Customers are trying to build members' site with SPA. After member authentication, APIs are called directly to Apigee Edge from the SPA running on the Web browser using the access token. I have concerns about this point.

Since SPA runs on the browser, authenticated members can easily obtain their access token. Because the access token is a "Bearer" token, it is also available from clients other than SPA.

As a countermeasure, SPA encrypts the access token (I understand that this does not make much sense) and shortens the expiration date of the access token, but it is not enough. In addition, we have to be able to withstand attacks such as CSRF.

I thought of a method such as holding a client's information (IP address,Browser info and so on) as a custom attribute of an access token, issuing a one-time jwt, and so on.

What is the best practice?

Solved Solved
1 3 1,428
1 ACCEPTED SOLUTION

Using tokens in a JavaScript-enabled web app (SPA)....This is the primary use case for the implicit grant in OAuth 2.0. You can read some discussion about this, on stackoverflow.

authenticated members can easily obtain their access token.

Yes, this is true.

Because the access token is a "Bearer" token, it is also available [could be used] from clients other than SPA.

Also true. The user would need to extract the token and specifically move it to another client, let's say curl. Then the user would need to use curl to invoke APIs on behalf of ... himself. This in itself is not a security issue. But, if the user's machine is hijacked, then I suppose a second client could grab a token, secretly. This pre-supposes a TLS exploit, or an insecure browser. If we are assuming a TLS exploit or hacked machine, then... there's no sense protecting a token, is there?

Even so, it is desirable to prevent migration of tokens from the originating app to a different app or client.

An approach involving binding the token to the client IP address is feasible using the approach you described. The approach is pretty easily implemented in Apigee Edge today. This will satisfy, with one small exception: secondary clients running on the same machine, using the same IP Address, can still re-use the token. If I run curl on my workstation, it uses the same IP address as my Chrome browser.

There is a proposed draft standard that allows tokens to be bound to a TLS context. This would prevent the tokens from being shared at all, even among clients running on the same machine.

https://tools.ietf.org/html/draft-ietf-tokbind-protocol-15

This will be a much more general solution to the problem you described. Unfortunately, it's not finalized yet.

View solution in original post

3 REPLIES 3

Using tokens in a JavaScript-enabled web app (SPA)....This is the primary use case for the implicit grant in OAuth 2.0. You can read some discussion about this, on stackoverflow.

authenticated members can easily obtain their access token.

Yes, this is true.

Because the access token is a "Bearer" token, it is also available [could be used] from clients other than SPA.

Also true. The user would need to extract the token and specifically move it to another client, let's say curl. Then the user would need to use curl to invoke APIs on behalf of ... himself. This in itself is not a security issue. But, if the user's machine is hijacked, then I suppose a second client could grab a token, secretly. This pre-supposes a TLS exploit, or an insecure browser. If we are assuming a TLS exploit or hacked machine, then... there's no sense protecting a token, is there?

Even so, it is desirable to prevent migration of tokens from the originating app to a different app or client.

An approach involving binding the token to the client IP address is feasible using the approach you described. The approach is pretty easily implemented in Apigee Edge today. This will satisfy, with one small exception: secondary clients running on the same machine, using the same IP Address, can still re-use the token. If I run curl on my workstation, it uses the same IP address as my Chrome browser.

There is a proposed draft standard that allows tokens to be bound to a TLS context. This would prevent the tokens from being shared at all, even among clients running on the same machine.

https://tools.ietf.org/html/draft-ietf-tokbind-protocol-15

This will be a much more general solution to the problem you described. Unfortunately, it's not finalized yet.

@Dino, Thank you for the detailed answer.

I understood that the best solution to the problem I'm worried about is token binding. Although it is currently a draft version, is there any plans to support this standard in Apigee in the future?

I also found out that users themselves extracting their own access tokens and using them on other clients is not a security issue. I would like to discuss with customers whether to take measures assuming TLS exploit.

The product team is observing the token-binding standard, and is evaluating whether we should include support for that explicitly in the product. Our decision to include a new feature is always a dynamic one - depending on industry standardization, industry importance, and customer demand.

Having said that, we don't have any plans to announce at this time for token-binding.

Regarding your desire to discuss how large a threat this is, it seems like a good topic for a community post. I encourage you to ask it here, in a new question.

I don't know how much attention it will receive.

It seems that the tendency is for non-Apigee community participants - customers - to view the Apigee Community as a forum where THEY post HOW-TO questions, and Apigeeks post HOW-TO answers. Unfortunately, Customers - the people you want to ask - generally don't contribute lots of answers. That's too bad. We at Apigee always envisioned the community as a digital forum in which all participants can interact and swap tips, or dialogue and exchange views on topics such as this one.

I hope you can ask your question - "How big a threat is this?" and start a conversation.

If not here, then maybe on https://security.stackexchange.com . If you ask externally, please let me know.