how can I Passing end-user details from client to real backend endpoint
I try the following URL but doesn't work with me
Passing end-user details from client to real backend endpoin
Related
I am a bit confused on how does Authorize.net work and how to integrate it, in my project I am using Angular as frontend and node.js as backend and I have installed Authorize.net via npm install authorizenet also cloned the Node.js sample code and I would like to set Authorize.net like so.
Let's say I have a form on my website where the customer needs to enter their details including the credit card details, my question is when submitting (using HTTP Request Method: POST) does my website need to redirect to Authorize or is there a widget that Authorize uses that I can implement in my website or are the details send directly to Authorize and handled there.
On submitting the details from the website do I simply call let's say the function from the sample codes (modified for my site) charge-credit-card.js ?
After that where do I receive the response, do I need to somehow capture it ?
Do I simply use the Production API Endpoint: https://api.authorize.net/xml/v1/request.apiand use my Api login and transaction key to use Authorize, at least that's the way in the documentation from my understanding - After building the XML object for an API request, submit it to the Authorize.net payment gateway as a standard HTTPS POST to an Authorize.net API endpoint. The exact process for doing this will depend upon the development language that you use.
Thank you in advance.
Your server will never know the customer's credit card details.
when user first time registers in your site then you will create one customer for authorize.net using this code and you will save the customer id returned to your db for future reference.
To Update customer's credit card details:
create one API controller from your node server which will return authenticating token from authorize.net to your frontend. Get token code
Your front end will make call to above created controller's API and get the authorize.net token.
Now, your front end will use this token to get the update details form from authorize.
Then you will use authorize webhook facility to know if user has updated theit payment details or not.
Webhooks to be tracked:
net.authorize.customer.paymentProfile.updated
net.authorize.customer.paymentProfile.created
On receiving below notifications, your node server will perform the whatever task required.
Refer this doc for more details.
I'm working on a project where the backend is built with the serverless framework. Recently, I added a feature using API Gateway's websockets. However, I have my doubts about my particular implementation's security, and wanted to ask how valid they were.
I struggled to build authentication into my websocket routes. There was an authorizer feature, but unfortunately native Javascript APIs provide no way to edit headers in a Websocket message - this means I would have to submit authorization tokens in the url params, which I would prefer not to do.
I came up with a workaround. I have existing HTTP microservices set up on API Gateway with serverless, authenticated through AWS Cognito Identity Federation. My solution was to "piggyback" my websocket authentication onto my HTTP services, as follows.
My client opens a websocket connection, and receives back the connectionId assigned to it by API Gateway.
My client calls an HTTP route with the connectionId, which is authenticated with Cognito. This serves to let my backend know that this particular connectionId is authenticated. I push the connectionId and the Cognito identity to a database, along with other information. This way, later I can find what connectionIds are associated with a particular Cognito identity.
When a client wants to call a "secured" websocket method, the websocket method checks the lookup table to see if that connectionId is associated with the correct Cognito identity. If it is, then the method goes through. Otherwise, the connection is closed.
I found this resource at Heroku on websocket safety which recommends a similar, but not quite identical process: https://devcenter.heroku.com/articles/websocket-security
It recommends the following:
"So, one pattern we’ve seen that seems to solve the WebSocket authentication problem well is a “ticket”-based authentication system. Broadly speaking, it works like this:
When the client-side code decides to open a WebSocket, it contacts the HTTP server to obtain an authorization “ticket”.
The server generates this ticket. It typically contains some sort of user/account ID, the IP of the client requesting the ticket, a timestamp, and any other sort of internal record
keeping you might need.
The server stores this ticket (i.e. in a database or cache), and also returns it to the client.
The client opens the WebSocket connection, and sends along this “ticket” as part of an initial handshake.
The server can then compare this ticket, check source IPs, verify that the ticket hasn’t been re-used and hasn’t expired, and do any other sort of permission checking. If all goes well, the WebSocket connection is now verified."
As far as I can tell, my method are heroku's are similar in that they both use an HTTP method to authenticate, but differ because
1) Heroku's method checks for authentication upon opening, while mine checks afterwards
2) Heroku's method requires generating and storing secure tokens
I don't want to send authorization over the websocket, because I'd have to store it in url params, and I also do not want to generate and store tokens, so I went with my method.
However, I have a couple of doubts about my method as well.
1) Because I don't check authorization on websocket open, in theory this approach is vulnerable to a dDos attack, where an attacker simply opens as many sockets as they can. My assumption here is that the responsibility falls on API Gateway to prevent, with its Leaky Bucket algorithm.
2) My strategy hinges on the connectionId being secure. If an attacker were able to spoof this connectionId, then my strategy would no longer work. I assume this connectionId is issued internally within API Gateway to mark specific connections, and should not be vulnerable as a result. However, I wanted to double check if this was the case.
I would suggest looking into JWT's. It was kind of created for this purpose where you need to have some way to authenticate client-side requests without exposing credentials. It is fully self contained and allows you to not make a request to a database everytime you make a request to validate the user making the request: https://jwt.io/
JWT's are very easy to implement in Serverless and attach to a web socket connection request. You can then do something like add the user IP address to the payload of the JWT and validate that at request time to ensure that the user is 100% validated.
I'm currently working on a REST based SagePay Integration using a combination of Django on the backend and Vue / Nuxt on the front.
The current process is as follows:
Client makes a request to my backend server for a merchantSessionKey via a GraphQL resolver.
The backend graphene resolver uses the secret merchant integration key and password (stored in environment variables) to make a post request for the merchantSessionKey and returns it to the Vue frontend.
A user fills in the credit card form (using SagePay's Own Form integration)
I use the card data to generate a cardIdentifier that I will store in my vuex state and will use later to further the rest of the transaction.
Is this all safe to do? Obviously it will be secured via https and I will setup CORS properly when everything goes into production, but I am technically storing the merchantSessionKey and cardIdentifier on the end users machine.
Both expire after 400sec and must be send together within Payment Registration POST authenticated with your vendor/account IntegrationKey and IntegrationPassword from your server which IP is whitelisted by Sage Pay. MSK is required to authenticate card tokenization call from customer's browser to Sage Pay endpoint. As a result you receive cardIdentifier/Token. This method keeps your server free of cardholder details but all (MSK,Token, PAN and CV2) are allowed to exist in customer browser.
IntegrationKey and IntegrationPassword can't be stored in the customer browser.
If you decide to use your own payment pages instead of drop-in checkout, you can't reference files from 3rd-party non-PCI DSS server to archive PCI DSS SAQ A-EP attestation.
I've reviewed it with QSA
Hi i am new to Apache cxf rest API security side.I want to rest API which have good security with authorization.I found Apache cxf gives Ouath2 security features(http://cxf.apache.org/docs/jax-rs-oauth2.html).So And i need to use json web token(http://jwt.io/) to send to API for authorization.Simply i need to use secured line for send request to rest API.So far i have simple design.
And my REST api have CRUD Operations to database.I thought send JWT as Access token in request header.And API side verify the user and send data back to user.I have two questions.First one is Is this the best design for this kind of application.And second one is if this is best way how to generate Tokens and is that we need to keep those tokens in server side.
Yes it's a good design
I can explain it with github web api's
Authorize
First u validate urself for using API by sending client id and callback url in request (here u specify access level ie.scope) and u receive a code
Access_token
Then u exchange this code for access token (this time with client secret included in req parameter)
This access token received is used for all future calls made by u on behalf of user
Nd ya u store this token and refresh token at server
https://developer.github.com/v3/oauth/#web-application-flow
Although this is specific to github , similar flow follows for twitter , linked in and slightly different for facebook web api's
My company provide services to other websites. I would like to be able to give them a simple snippet of code to embed in their site (like a widget) that will send a query to the service I'm implementing, receive a response and render the results in the page. I'd like to minimize their effort, and only give them the smallest snippet possible. This is also why I'd like to keep it all client side.
The problem is that I'd like to make sure that the call is actually made by my clients and not by anyone else who copied the code from the site. I looked into the web client oauth2 flow, but it seems that it does not enable to authenticate the client. It does say that there's a way to validate the client by comparing the callback URL to a URL that the client registered with my service.
My Questions:
Is there any better approach?
Is the oauth2 client side approach, including the method described to validate the client, sufficiently secure?
If I go for the suggested implementation, what should I pay attention to?
You could use the Client Credentials Grant Authorization as defined in OAuth-2.0. This would allow you assign a separate Client Token and Client Secret for each separate client and they send in the tokens to get an access token and use the access token to request the data.
Or you could just skip the OAuth all together and use SOAP WS-Security with certificates assigned to each client to authorize the web service.