I have a MEAN stack web app and I use REST API to connect to the database.
My question is how can I protect it from unwanted http requests?
I already use token verification (JWT) before accessing the database but if the attacker has a token (all he needs is to register to the web app) then he'll be able to access it.
Thanks
Related
We are looking into integrating keycloak to protect a front end AngularJS application which is served by a nodeJS application and also makes API requests to this server.
Having watched some tutorials, we see we need to use the javascript adapter for the AngularJS app to handle the user auth flow, and then protect our nodeJS application using the bearer only strategy, ensuring angularJS outgoing requests to our Node application contains an Auth header with the bearer token value present.
I have a question\concern about the way in which the token is being served back to the client as I can see it gets saved into a cookie which I assume is what the javascript adapter reads from in order for us to be able to write the Auth header into subsequent requests from the angular app.
My question is can this token value be easily read from the browser cookie and used maliciously by an attacker trying to make api requests?
Am I right in thinking it would be highly unlikely since the attacker would need to know the secret which is stored on the nodeJS side?
You don't need to know the client secret to use access token. That secret is used only to issue access token. If someone has your unexpired access token, then that someone will be able to use your identity until token expires. But you can minimise the possibility of the stolen access token by using https, httponly cookies. Also, you can use a short token lifetime (for example 5 minute). But then you will need to implement refresh tokens; otherwise, the user will need to re-login whenever access token expires.
I think the proper implementation is not trivial. I recommend using of some reverse auth-proxy, which will handle authorization and authentification in front of your app. Tip: https://github.com/gambol99/keycloak-proxy
I am trying to implement the Authorization Code flow described in RFC 6749 (OAuth 2.0) for a JavaScript-based application. I understand that I should use a web server back-end as a confidential client so that it can protect the access token and refresh token returned by the authorization server and not pass them on to the JavaScript front-end. Then all requests from the front-end to any protected resources go via the web server back-end, which attaches the access token to the request and proxies it on.
My question is how do I let the JavaScript front-end make use of these tokens in a secure way? I assume that I have to do something like set up a session on the web server and pass back a cookie that identifies the session. But this means that the JavaScript application then has a cookie that gives them the same privileges as if they just had direct access to the bearer tokens stored in the web server. How does having a web server to hold the tokens give extra security?
I understand that I should use a web server back-end as a confidential client so that it can protect the access token and refresh token returned by the authorization server and not pass them on to the JavaScript front-end.
No, it is a misunderstanding of the OAuth2 flows and goals.
Here is the OAuth2 main goal: your application (which can for instance be a JavaScript program running in the browser, a web server, both, etc.) MUST NOT need to know the user's credentials (most of the time a login/password pair) to access the service on behalf of the user.
Here is the way OAuth2 must be used to achieve this goal:
according to your needs, that is having a Javascript-based application running in the browser (i.e. not a node.js application), you need to use the OAuth2 implicit flow, not the authorization code flow. But of course, because your application is running in the browser, it will not be able to persist the credentials to access the resource offered by the service provider. The user will have to authenticate to the service provider for each new session on your application.
when your application needs to access the service provider when the user is not logged in, or when your application is able to persist credentials (because your application has its own credential system to identify its users), your application does not only rely on a JavaScript program running in the browser. It may rely only on a web server, or on both a web server and a JavaScript program that talks to this server. So, in those cases, you must use the authorization code flow.
So, as a conclusion, you have decided to add a web server to your application because you thought you had to use the authorization code flow. But in your case, you probably do not have to use this code flow, therefore you should select the appropriate code flow for your application: implicit code flow. And this way, you do not have to add a web server to run your application.
How does having a web server to hold the tokens give extra security?
This does not give extra security. Having a web server to hold the tokens is simply a way to let your application access the service on behalf of the user, in the background, when the user is not logged on your application.
While I agree with Alexandre Fenyo's comments, I just want to add the 2021 version. You should no longer be using the implicit flow as this is no longer considered secure.
For scenarios such as this where a JavaScript application has to handle tokens I would suggest using the Authorization Code flow with PKCE instead: https://auth0.com/docs/flows/authorization-code-flow-with-proof-key-for-code-exchange-pkce
I have Oauth2 implemented in my application to protect API calls.
My Oauth and resource server are on two separate physical boxes(but on same network). For each call on resource server it needs to call Oauth server for Oauthtoken validation.
I have millions of request coming to my resource server in a day.
Currently to validate Oauth token I am using rest call from resource Server to Oauth Server.
Is there a way to make this faster as each and every call needs to be redirected to Oauth server? Can webSockets solve this problem?
If you don't need to revoke individual access tokens, you can use stateless (JSON Web Token) JWT tokens. JWTs don't need to be validated on the authorization server. As long as the JWT token is signed by the authorization server (asymmetric cryptography), you can validate the token on the resource server itself using the authorization server's public key.
This makes for fast authorization (since it skips a server-to-server round trip) at the cost of easy revocability.
Note: you can also use a shared secret (symmetric cryptography) but then you need to make sure all the interested parties have the shared secret (and keep it secret).
Look into spring-security-jwt and https://jwt.io/
I have a set of REST APIs that are secured by oauth 2. I need to access them from an Android app and a webapp.
Accessing the APIs from android app seems pretty straight forward for me to implement. What I am unable to understand here is - what is the correct and secure way to access the same APIs from a webapp?
I am thinking, I shouldn't be making any direct calls to the APIs from the browser, using some JS library, for it seems to me that it would be pretty insecure. Instead, I should keep it all traditional, by submitting requests to the web server and then letting it make the REST API call. This would be similar to the method of making REST calls from Android.
Am I correct in my thinking/approach?
Accessing your API should be the same no matter where the request is coming from. You just use an Authorization header with bearer scheme and stick the JWT token in there.
The way you get the JWT token is different though, as I explain in this answer. It all depends on how much you trust the client application.
If your client is a web application that queries your API from the server side, you can use the code authorization grant and get an access and refresh token for your API.
If you want to access your API from a JavaScript application, you have no way to hide app-keys or refresh tokens, so you should use the implicit grant.
If you know how to store secrets securely on your Android client, you could use the resource owner password grant.
The code authorization grant is definitively the most secure as it's much harder to compromise a server application than an application that runs on your machine.
I am creating a solution that will contains a website and mobile apps. I will use Zend-Framework 2 for the website.
So, to make it good, I am wondering if it would be a good idea to build :
A REST web service (using zf2)
Another website that will call the REST ws (using zf2)
The mobile apps that will call the REST ws
I will use OAuth for the autentication and security.
My question is, if my website gets the data by calling the REST ws, it will have to make a database request at each call to check the token whereas if I do a "normal" website, my app will be able to use session to store the information of the connected user.
Because, for what I have read, there is no such thing as session with OAuth/REST so for each call, I have one more sql request to check the token validity.
Is it still a good idea to make a full REST service, even for the website or to have a "normal" website and also a REST service API just for the mobile apps ?
Thanks
Oauth is a server to server authentication framework. Like it is between mobile app and your API server , website vs your API server etc. You can adopt an approach where , you generate only one access token for your website client instead of multiple access token for each user from the website. This access token is stored in your webserver vs user cookie in website.Ultimately the aim is to identify all the clients of your REST WS and your website is one of its client and a very trusted one.
This way you can cache the access token to avoid db calls (typically cache time can be equal to or less than token expiry time). Do explore the multiple grant types specified in the oauth spec for this
Regarding maintaining session for user in your website, it is not dependent on whether the back end is a REST WS or not, it can be handled in your website