I'm using a service with REST api, which provides me an authentication token as the response for the sign in POST request. Where is it better (and secure) to store? This token should be added to each request after that.
Use Keychain Services to store passwords and tokens.
Use this https://github.com/granoff/Lockbox . Simple way without knowing the apis
Related
Consider I'm creating a RESTful API (like Twitter API) and I need only a single key token to access the endpoint GET /messages.
The token needs to be sent via header access_token for example.
If I don't pass the token I'll get an 4xx error.
In the RESTful API scenario, is this all needed to protect against CSRF attacks? I mean, in RESTful APIs I'm not using Cookies to manager a user session, since the idea here is to not be a session (Stateless is one of the principles of REST).
Am I forgetting something or is this correct? I don't see why I would need a anti CSRF token besides my access token.
Thanks in advance!
Short answer: if your access_token is not a cookie, yes, it's enough to protect you against CSRF.
Long answer:
A CSRF attack can only happen when HTTP client automatically sends some authentication data(usually cookies) to server. The key point is attacker do not need to know the Cookie, it's is automatically sent if web user accesses 2 sites(your site and the attacker's site) using the same browser.
To anti CSRF, server sends to client a private token that browser does not automatically send it to server(so it's must not be a cookie). The developer has to write code to attach the token to each subsequent request.
CSRF is an issue for using Cookie by Web browser, if you are developing restful API that is not used by web browser, usually, you do not need to care about CSRF
#Bart Firstly CSRF attacks are usually from a trusted user. Which means that the client has successfully authenticated himself by maybe passing a valid token in case of a rest API. The attack could be by passing let's say a javascript which can change the state of a resource. So just having a single key token won't really help to avoid CSRF attacks.
Please refer to below URL for more reference on CSRF :-
https://en.wikipedia.org/wiki/Cross-site_request_forgery
Most of the frameworks like Spring have inbuilt support for CSRF.
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 have a website allowing authenticated users to submit and edit data. I also want to offer a REST API as part of a chargeable service.
Now the problem is that a non-paying user could theoretically use the same calls my website uses as API for authentication and sending data from his external application since it is very easy in the browser to see the endpoint what and how exactly the data is being sent to a website.
How can I protect my website from such usage and force the user to use API for external access?
Actually you cannot prevent people making requests to a public API. You can just validate the user when a request arrives. So there are more than one approach to solve this problem.
I would provide a token per session for each user and validate the rest API request at back-end.
Use OAuth2. So you will give paid user secret id and key then they will ask for the access token to access the API's using secret id and key.
Read about public/private key encryption https://en.wikipedia.org/wiki/Public-key_cryptography
Read about oAuth
https://oauth.net/2/
I have used passport to implement oAuth2 in laravel. passport is oAuth2 implementation and available in other languages also.
When I use public APIs from web applications, I am provided with an API key that I use inside my client, as a string.
Now suppose I design a REST API for internal consumption. Let's say for a mobile app eshop. The user of the eshop logs in with a username and a password.
Does that mean that my client won't use API key authentication but username and password? I also see OAuth2 a lot in REST APIs, which also seems like a key-oriented authentication. Are they just different types, all valid ones? The API keys are usually issued for developers though, could that work with customers?
It could work and it's also what you will be seeing in many cases. You login with username and password (POST request) and the server returns you an authentication token which you store in a Cookie through response headers. When user specific information is being required you would be using that token to authenticate, similar to how OAuth2 and dev keys work.
Based on my understanding on your question -
There are methods or way on how you can authenticate your api. Some of the common ones are through Oauth, Token authentication and Basic auth (username and password).
You can read some of the concepts here - http://www.django-rest-framework.org/api-guide/authentication/
Hope this helps
I'm in the middle of writing a RESTFUL API in Hapi, I could not figure out API authentication methodologies.
Assuming we're using SSL/TLS with HTTP/1.1, why do we need something like JSON Web Token (JWT), where we already have HTTP Basic Authentication. We may protect every endpoint with HTTP Basic Auth, so we wouldn't even need login routes like '/login'.
So, what's the point of those authentication schemes, OAuth's and JWT?
Thank you.
OAuth and JWT use tokens, not passwords. Tokens are uniquely generated per application and site. If someone steals a token, they have not stolen your password, and that token is only good for that session only.
Contrast this with basic auth, it's an actual user password. Not only can they re-use that password whenever they want, they can also use that password with any other service that uses the same password. Stealing a token doesn't allow that to work.