I've an API that uses OAuth authentication (hydra) to authenticated requests that are
coming from the user browser.
I would also like to send requests to the same API's also from another backend (NodeJS).
I'm a bit confused what is the best way to do it.
The current Authentication mechanism uses a refresh token (1h).
I was thinking about creating another client for the backend in hydra, but it seems strange that also the backend will use the same method with the refresh token like the browser (never saw this before).
Any help with how to address this issue will be appreciated.
So... there are several concepts you might need to take into consideration here...
Since its conception the OAuth 2.0 family of standards distinguishes between private (trusted) and public (potentially vulnerable to attacks) clients. The client you've got running in the browser falls in the latter category, and thus most experienced OAuth devs out there would argue that it's not OK to use refresh tokens for this client. For you backend service (even if it is a simple backend-for-frontend) written in node, that's a completely different story - there it's OK to use and store refresh tokens.
If however your node.js backend is working "outside" an active customer session, i.e. tries to access customer data even when no customer is actively interacting with the frontend, you might also want to consider the machine-to-machine flow provided by OAuth 2.0 - the Client Credentials Flow.
Related
I am planing to make a simple admin CP. Im oldschool PHP developer where usually all is in one huge monolith server and concept of microservices does not apply.
In my next app I would like to have:
Express UI (Frontend) <----> REST/GraphQL API <-----> DB server
The idea is to limit access to DB as much as possible. All requests from users would go to frontend only and API would be used only internally by other servers in my solution.
I will set up IP filters between API and DB, and likely between Frontend and API. But my concern is - say I want one admin to create a product. While this user will be authenticated on frontend using sessions, I need requests going to API to be somewhat authenticated too. Ignoring IP filters for now, do not want just about anybody to be able to send REST requests to API.
I have several ideas, please give me your opinion:
sharing express-session between API and frontend using mongodb (likely on yet another server) - I see latency issues
putting API service on same server as frontend and use redis to share sessions - kinda defeats the purpose of microservice separation
on login, generating jsonwebtoken that is always fwded between frontend and API for any user action - cookie stealing will be an issue, since i can only verify user logged in, not that he authorized certain action to be performed
on login, sending private key to admin and have him sign all requests that are fwded to API - this looks like a CPU overkill
Is there any generally used solution I am missing? Is separating frontend and API mitm overkill, or a good practice? I could easily merge the 2 and talk to DB directly from frontend, then i can manage everything with sessions just like with PHP.
Thanks for any inputs! Cheers
A more elaborate implementation of (1) is the use of a session server. The idea is to purely remove database lookup latency but not the bottleneck of session lookup in general. It acts as a caching layer. A zero coding implementation is to use something like redis or memcache as the session storage.
In general though, a cryptographic signing mechanism like JWT would be much more scalable because it involves zero I/O lookup. All you do is verify that the token is properly signed. And as long as you keep your application secret safe you're secure. You can even encode things like user roles and permissions directly in the token to completely avoid querying the database for it.
The key idea of JWT is that all the security is hidden in the backend. The front-end only echos back the token to the server as proof of authentication.
But since the front-end stores the token, it can be hijacked by javascript. One solution is to use HttpOnly cookies as the mechanism to transmit the tokens. I've even seen implementations where the main part of the token is sent in the Authorization header but the signature is sent in a HttpOnly cookie. This prevents scripts from being able to read the entire token.
We have a simple setup: An authorization server based on OAuth 2.0, which currently only supports the client_credentials grant type. Then we have an API, the resource server, which is protected by requiring an access token from our OAuth server.
All use-cases for our API so far, have been pure machine-to-machine communcation, where it's simply our customers servers running batch jobs.
Today I had a meeting with a new customer. They have an SPA that seemingly does not have its own backend server. It uses AWS for authenticating, and seems to return a JWT, but from what I can tell, they make a lot of API calls directly to publicly available services, and then the logic is all performed in the SPA.
We ideally would've liked them to simply register a single OAuth client with us, so that when users make a request that needs one of our APIs, the request is first routed to their server, which performs the lookup, and then uses their client's credentials to contact our server. But they would prefer to not have to set up a backend. In this case I'm kind of at a loss for how we sensibly let them integrate with our system. They would prefer to send their user's JWT to our system, but I don't think they understand that we would need their key to verify the user's signature in that case, and we don't want to have to create new APIs simply for this purpose.
Would very much appreciate any advice on this issue - thanks very much in advance for any help.
We ideally would've liked them to simply register a single OAuth
client with us, so that when users make a request that needs one of
our APIs, the request is first routed to their server, which performs
the lookup, and then uses their client's credentials to contact our
server.
Your recommended approach is the right way of doing it with Client Credentials Grant.
They would prefer to send their user's JWT to our system, but I don't
think they understand that we would need their key to verify the
user's signature in that case, and we don't want to have to create new
APIs simply for this purpose.
If the previous approach doesn't work, I'm afraid that this is the only way of doing it. You will need to implement a Proxy to validate the JWT (You should be able to get their public key to verify the signature). You can do this in AWS itself, using AWS API Gateway + Lambda to verify the JWT to and forward the request to your existing backend with Client Credentials Grant where you don't need to pay anything upfront.
For the last few months i've been working on a Rest API for a web app for the company I work for. The endpoints supply data such as transaction history, user data, and data for support tickets. However, I keep running into one issue that always seems to set me back to some extent.
The issue I seem to keep running into is how do I handle user authentication for the Rest API securely? All data is going to be sent over a SSL connection, but there's a part of me that's paranoid about potential security problems that could arise. As it currently stands when a client attempts to login the client must provide a username or email address, and a password to a login endpoint (E.G "/api/login"). Along with with this information, a browser fingerprint must be supplied through header of the request that's sending the login credentials. The API then validates whether or not the specified user exists, checks whether or not the password supplied is correct, and stores the fingerprint in a database model. To access any other endpoints in the API a valid token from logging in, and a valid browser fingerprint are required.
I've been using browser fingerprints as a means to prevent token-hijacking, and as a way make sure that the same device used to login is being used to make the requests. However, I have noticed a scenario where this practice backfires on me. The client-side library i'm using to generate browser fingerprints isn't always accurate. Sometimes the library spits out a different fingerprint entirely. Which causes some client requests to fail as the different fingerprint isn't recognized by the API as being valid. I would like to keep track of what devices are used to make requests to the API. Is there a more consistent way of doing so, while still protecting tokens from being hijacked?
When thinking of the previous question, there is another one that also comes to mind. How do I store auth tokens on client-side securely, or in a way that makes it difficult for someone to obtain the tokens through malicious means such as a xss-attack? I understand setting a strict Content-Security Policy on browser based clients can be effective in defending against xss-attacks. However, I still get paranoid about storing tokens as cookies or in local storage.
I understand oauth2 is usually a good solution to user authentication, and I have considered using it before to deal with this problem. Although, i'm writing the API using Flask, and i'm also using JSON Web tokens. As it currently stands, Flask's implementation of oauth2 has no way to use JWTs as access tokens when using oauth for authentication.
This is my first large-scale project where I have had to deal with this issue and i am not sure what to do. Any help, advice, or critiques are appreciated. I'm in need of the help right now.
Put an API Gateway in front of your API , your API Gateway is publicly ( i.e in the DMZ ) exposed while the actual API are internal.
You can look into Kong..
I have poured over the OAuth2 docs and seen how the Facebook Javascript SDK uses Implicit Grant.
I am building a ReactJs application, which communicates with a PHP-Symfony API.
What I want to do is offer the "Login with Facebook" option on the frontend.
What I need on my PHP server is the Facebook user id and email and other data of the user so I can initially create a user record for them in my DB and then on returning visit, use the auth token to get that info again on the server and use it to match it to existing records and log the user in.
We have done this previously using the Authorization Code Grant method to redirect the frontend to our server, then to facebook and then back to us with the auth code. We then use that on the server with our Secret Key to get the Access Token and get the user info directly from Facebook to our server and then authenticate the user.
The redirection is a bit of a pain for a single page application.
Facebook's Javascript SDK handles a lot of that automatically, but uses Implicit Grant, returning an Access Token directly to the frontend.
What I want to know is, can I just send that Access Token to my server to do the same type of authentication that I did before? Or is that a massive security hole that I am opening up?
Comparing the two, the Auth Code from the Authorization Code Grant flow also goes via the frontend, but very quickly, not directly to JavaScript and is much shorter lived. So it feels much more secure.
If intercepted in time and with matching state, it could be used to authenticate someone on our server, but not access someone's Facebook data directly.
Reusing the frontend Access Token from the Implicit Grant flow feels like it is open to messing with, but I can't put my finger on the exact scenario that would make it more vulnerable to attack. The token would potentially give people access to not only authenticating on our server but also to accessing people's Facebook info.
So this is ultimately a question of best practice and security.
We think that we should be able to implement our own popout window that does the Authorization Code Grant style flow and retrieves our server cookie which can then be used by the page that spawned it, but it is going to be tricky and most of the work seems to be done for the Implicit Grant method, if it is safe to use as we intend to use it.
Best Practices AND According to the RFC 6749
However, this convenience should be weighed against the security
implications of using implicit grants, such as those described in
Sections 10.3 and 10.16, especially when the authorization code
grant type is available.
I'm developing the restful web app that using some popular web framework on the backend, say (rails, sinatra, flask, express.js). Ideally, I want to develop client side with Backbone.js. How do I let only my javascript client side interact with those API calls? I don't want those API calls to be public and be called by curl or simply by entering the link on browser.
As a first principle, if your API is consumed by your JS client, you have to assume, that it is public: A simple JS debugger puts an attacker into a position, where he can send a byte-for-byte identical request from a tool of his choice.
That said, if I read your question correctly, this is not, what you want to avoid: What you really don't want to happen is, that your API is consumed (on a regular basis) without your JS client being involved. Here are some ideas on how to if not enforce, then at least encourage using your client:
I am sure, your API has some sort of authentication field (e.g. Hash computed on the client). If not, take a look at This SO question. Make sure you use a salt (or even API key) that is given to your JS client on a session basis (a.o.t. hardcoded). This way, an unauthorized consumer of your API is forced into much more work.
On loading the JS client, remember some HTTP headers (user agent comes to mind) and the IP address and ask for reauthentication if they change, employing blacklists for the usual suspects. This forces an attacker to do his homework more thoroughly again.
On the server side, remember the last few API calls, and before allowing another one, check if business logic allows for the new one right now: This denies an attacker the ability to concentrate many of his sessions into one session with your server: In combination with the other measures, this will make an abuser easy detectable.
I might not have said that with the necessary clarity: I consider it impossible to make it completely impossible for an abuser to consume your service, but you can make it so hard, it might not be worth the hassle.
You should implement some sort of authentication system. One good way to handle this is to define some expected header variables. For example, you can have an auth/login API call that returns a session token. Subsequent calls to your API will expect a session token to be set in an HTTP header variable with a specific name like 'your-api-token'.
Alternatively many systems create access tokens or keys that are expected (like youtube, facebook or twitter) using some sort of api account system. In those cases, your client would have to store these in some manner in the client.
Then it's simply a matter of adding a check for the session into your REST framework and throwing an exception. If at all possible the status code (to be restful) would be a 401 error.
There's an open standard now called "JSON Web Token",
see https://jwt.io/ & https://en.wikipedia.org/wiki/JSON_Web_Token
JSON Web Token (JWT) is a JSON-based open standard (RFC 7519) for
creating tokens that assert some number of claims. For example, a
server could generate a token that has the claim "logged in as admin"
and provide that to a client. The client could then use that token to
prove that they are logged in as admin. The tokens are signed by the
server's key, so the server is able to verify that the token is
legitimate. The tokens are designed to be compact, URL-safe and usable
especially in web browser single sign-on (SSO) context. JWT claims can
be typically used to pass identity of authenticated users between an
identity provider and a service provider, or any other type of claims
as required by business processes.[1][2] The tokens can also be
authenticated and encrypted.[3][4]
Set a SESSION var on the server when the client first loads your index.html (or backbone.js etc.)
Check this var on the server-side on every API call.
P.S. this is not a "security" solution!!! This is just to ease the load on your server so people don't abuse it or "hotlink" your API from other websites and apps.
Excuse me #MarkAmery and Eugene, but that is incorrect.
Your js+html (client) app running in the browser CAN be set up to exclude unauthorized direct calls to the API as follows:
First step: Set up the API to require authentication. The client must first authenticate itself via the server (or some other security server) for example asking the human user to provide the correct password.
Before authentication the calls to the API are not accepted.
During authentication a "token" is returned.
After authentication only API calls with the authentication "token" will be accepted.
Of course at this stage only authorized users who have the password can access the API, although if they are programmers debugging the app, they can access it directly for testing purposes.
Second step: Now set up an extra security API, that is to be called within a short limit of time after the client js+html app was initially requested from the server. This "callback" will tell the server that the client was downloaded successfully. Restrict your REST API calls to work only if the client was requested recently and successfully.
Now in order to use your API they must first download the client and actually run it in a browser. Only after successfully receiving the callback, and then user entry within a short frame of time, will the API accept calls.
So you do not have to worry that this may be an unauthorized user without credentials.
(The title of the question, 'How do I secure REST API calls', and from most of what you say, that is your major concern, and not the literal question of HOW your API is called, but rather BY WHOM, correct?)
Here's what I do:
Secure the API with an HTTP Header with calls such as X-APITOKEN:
Use session variables in PHP. Have a login system in place and save the user token in session variables.
Call JS code with Ajax to PHP and use the session variable with curl to call the API. That way, if the session variable is not set, it won't call and the PHP code contains the Access Token to the API.