I've looked at various approaches to this but I'm yet to find one that is perfect for my set up.
I have a UI that calls the api to present data to a user - the UI doesn't require someone to login and i don't want to authenticate every user. What i'm trying to do is simply protect the api because with the url to the api, anyone will be able to access the data.
In my mind, i can create a password/ apikey of some sort and store that as an environment variable that is sent from the UI to the API whenever a request is made. On the API, that apikey/password is validated before allowing access to the api.
Does this sound wise? Would you suggest something else? Have i missed anything. All thoughts are welcome.
The solution sounds good to me. You can do something like this:
back-end: create a new REST endpoint (something like /api/get-token) in your Node.JS application which generates a token (or ID), saves it locally (maybe into a DBMS) and returns it as response. Then, in every endpoint you need to protect, you extract the token from the request and, before sending any "private" data, you check if the supplied token is valid, or not.
front-end: as soon as your application is loaded, you send a request to the newly created REST endpoint and store the given token locally (localStorage should be fine). Then, every time the UI needs to access "private" data, you simply supply the claim within the request.
The implementation should be pretty straight forward.
Related
In order to restrict actions to specific tokens I need to check if a request made to my api is made from an frontend or backend application.
I want to implement the same behavior like Stripe. Using a secret key on client side will result in an error.
So is there a safe way to check this?
The answer could be through the User Agent, but in fact there is no exact way to identify and differentiate whether a request came from a browser or from another API for example, as it is possible to manipulate the User Agent.
Well-behaved "bots" (like common search engine spiders) will identify themselves using a User Agent specific to them.
Noob here working on first backend project.
What I’m trying to do...
Collect member data via my form (name, email)
User clicks paypal button to pay for membership
When payment approved by paypal, send post request with form data to my members endpoint to add new member
I now realize if I use postman to post to my members endpoint it works. So a malicious user could post data to my members endpoint regardless of paypals payment approval.
My understanding so far is that if my server allows CORS and I don’t password verify the user, anyone can post to that endpoint.
Is it possible to allow post requests only after payment approval without the use of a password?
I’m thinking of online stores that let you checkout without a password. How do they post the collected form data to their db without jeopardizing their post route?
Hope this wasn’t too vague. Pointers would be greatly appreciated!
I’m using node/express, but since it’s a general question I assume it doesn’t really matter..
These answers helped but still didn’t get me there.
Protecting post routes NodeJS
Can I only accept traffic from certain requesting domains with Expressjs?
So post / get request in general are functions of the browser and or server, I can create a simple html form and post to any URL I want to.. Now the question is, will it accept it or not.
When communicating between servers and web-services unless open to the public will use token based authentication to validate the request. So in terms of paypal, the typical flow would be.
(note, very oversimplification below and is just a sample of one such pattern)
User clicks paypal button from your site ( this will contain some type of paypal ID of sorts )
User is directed to paypal and after completing the transaction paypal redirects users back to your server with a token
your server reads the token ( sends API call to paypal with token to verify its valid, if success then process the post )
You can't prevent a user from posting data to a URL, however you can tell the server what to do if they do. So protecting your route from unauthorized post can be handled by sessions, tokens etc. For example, if you have a route on your server, lets call it user profile. This route first executes a check for the session, if its there keep processing, if its not, redirect the user.. Its really no different for callbacks / token auth.
Essentially, you will need to handle what the server does in your code because anyone can post to the endpoint.
To your other question about how companies handle guest checkouts, this can be done a few ways but one way is to create your own token, this token would be an encrypted string that may contain a cart ID, time etc.
When a user clicks 'checkout' the token is generated and passed to the server via a get or post request. From there your server decodes the token and if everything is correct processes the order otherwise it kicks it back.
Again, you see a lot of token based stuff here going on and that because there is an X factor in all of this.. the user.. We know who the server is but the user can be from anywhere and the user isn't a server so we need some way to maintain state between servers, hence tokens, encryption, JWT etc
I'm attempting to use the new Constant Contact V3 API to add a new email contact. I've been reading the docs: https://v3.developer.constantcontact.com/api_guide/client_flow.html, and trying it out and it seems like the only way to do this now is to make an authentication request, approve the request and then retrieve and access token that is valid for only 2 hours.
I need to have access from my server only and just send an add contact request to Constant Contact. I don't understand why I require to have a redirect uri now and an access token to use the V3 api instead of just using the api key.
With the V2 api I was able to make these types of requests directly from the server without hassle and that's exactly what I need now. The V2 documentation seems to be taken down so I can no longer do that so I'm stuck.
Any help is appreciated.
Based on this link: https://community.constantcontact.com/t5/Developer-Support-ask-questions/v2-or-v3-API-for-very-basic-integration/m-p/324777#M11434, it seems like server-to-server auth is not available still. For those of you who have the same issue, use Mail Chimp or another service that has basic api requirements.
You can get INITIAL Access Token without any code - just use your browser and curl. The Access Token is valid for 24 h, but you can automatically renew it using Refresh Token. You can renew it automatically every time it expires and never need to proceed through INITIAL flow over again. You can read about it here. If you are using C#, I have templates and instructions exactly for your scenario here: https://github.com/mikeks/constantcontact-v3.
I have a problem with the following scenario using MobileFirst HTTP javascript adapters:
let's say the adapters call 2 methods,
login, that calls a back end service which authenticates the user and also returns a customer_id (input: a username and a password).
retrieveData (protected by security-check) that retrieves sensitive data about a customer by calling a back end service (input: customer_id).
How can we make sure that some client that has credentials to authenticate and have access to retrieveData, will request only data that concern him and not be able to send a request sto retrieveData with a different customer_id from his own? (We assume that this client has tempered with the app and has made it send different customer_id's.)
With MobileFirst 7, after login was successful, we would call setActiveUser setting the returned customer_id as an atttribute of active user or we would call WL.Server.getClientRequest().getSession().setAttribute and again set the customer_id. So when a user called retrieveData, we would take his customer_id input and compare it to the customer_id in his session. If it was different, then they would get an error because they requested data that do not belong to them.
Since MobileFirst 8 does not have a session, how can we prevent this scenario from happening?
In 8.0, "Client Registration Data" is the closest thing to a session.
There are a lot of unknowns about your use case, but I will try to describe the expected behavior is most cases:
Assuming your security check extends UserAuthenticationSecurityCheck, as soon as the user succeeds to login, his user id will be registered in the client registration data on the server. This will map the client to the user in a database.
From that point on, on any adapter you can safely check who is the currently logged-in user by using securityContext.getAuthenticatedUser().
If you want to make sure that a client only accesses data it is allowed to, use this getAuthenticatedUser to check against your database that the requested data belongs to it.
If you really need to store extra custom data in the registration context (the closest thing to a session object) there are APIs in the security check to do so. See RegistrationContext.
In v8.0, the client is able to retrieve information from the backend system because it passed the challenge presented to it, and in return received an access token that enables it to access resources that are protected by a scope, which you define. This is how OAuth works more or less.
Have you read the Authentication Concepts tutorial? https://mobilefirstplatform.ibmcloud.com/tutorials/en/foundation/8.0/authentication-and-security/
I want to retrieve a list of recent photos with a given tag to display on a website in a very simple gallery.
For that, the doc says I need an access token. However, it seems that the only way to authenticate against Instagram is through OAuth; which involves sending the user to instagram and allowing my application access to their basic data. However, I don't want my users to do anything; I'd like my application to authenticate against Instagram for me and then retrieve the data I want.
Sounds simple, but all online documentation seems to end up in "Redirect your user to...". And I find no sensible ways to do this programatically; it's all about sending users away, letting them authenticate, and then receiving the access token afterwards. I could of course scrape the HTML, parse the forms (for example, the unique-per-session csrfmiddlewaretoken field which needs to be posted along with login requests etc) and let my server side application pretend to be my own user and login/authorize the app, but that doesn't seem like the way to go.
I could also just authenticate manually in the browser, pick up the auth token and paste into my application; but as the doc says: "do not assume your access_token is valid forever." - so I'd like this to be fully automated.
If I try to create a WebClient and POST to https://www.instagram.com/oauth/authorize/?client_id={clientId}&redirect_uri={redirectUri}&response_type=code&scope=basic it just returns a 403 Forbidden which is of no use. (For what it's worth, I'm using C# and have found instasharp, but this problem is not tied to any given platform...)
Am I completely overlooking something, or am I right that server side authentication against Instagram has become really complicated? Most other social media platform API's I've touched lets me get some form of authentication token just by posting a combination of the application id and secret.