I'm going to add PAYFORT integration Hosted Installments to my website
and got confused in a point:
Should i generate the Token in the client side(js request) or server side (Python), what makes it confusing that i need to send access_code and merchant_identifier in the TOKENIZATION request
it's not mentioned in the docs that these keys are confidential or not
Could anyone please used this integration advice me?
Thanks
merchant_identifier and access_code are not confidential, however tokenization only from client side :POST
you can find the merchant_identifier and access_code in payfort admin panel when select security setting
and this is static in you application but with that you must send other information to success your process from client side like merchant_reference , language , expiry_date ,card_number, card_security_code to create signature and then send your request with signature to payfort api with all of these information
i hope help you with this explain
Related
I'd like to understand how to make sure that only intended clients are connecting to API server?
For example there is an end point: http://example.com/v1/api/getallcustomers
Users will be authenticated
Token will be issued
Authentication will be done on every request
But I'd like to make sure only my Web and Mobile apps are connecting to this API. I would like to block/deny all other incoming connections even you know the end point. Please help. Thank you.
Cheers,
I'd like to make sure only my Web and Mobile apps are connecting to this API. I would like to block/deny all other incoming connections even you know the end point.
That is impossible since anyone who knows how the API works and has access to a valid authentication token can make a request (using Node.js, for example). You have no way of distinguishing a request made from your app from one made from some other program.
I am looking for sample about Asymmetric SMART on FHIR. Can someone help where/how the introspectionUrl generated using #asymmetrik/sof-strategy?
The introspection url is part of an OAuth2 server that needs to be setup and configured by someone building the FHIR server. We use that module in both our repos (https://github.com/Asymmetrik/node-fhir-server-core, https://github.com/Asymmetrik/graphql-fhir), but it requires an external OAuth2 server. You can read a little more on that here, https://github.com/Asymmetrik/node-fhir-server-core/wiki/Access-Control#available-built-in-options, and here, http://hl7.org/fhir/smart-app-launch/.
If you are not integrating with someone else's SMART enabled OAuth2 server, you can check out projects like https://github.com/mitreid-connect/OpenID-Connect-Java-Spring-Server. We used this server for one of our demo server's in the past and it will give you the endpoint's you need for #asymmetrik/sof-strategy.
I was thinking about a way to ensure that the authenticated client (by username, password, OAuth) is using the official client, and not a third side one which sends requests to the server, assuming that the official client can be decompiled and the code is revealed.
What's the best solution for this security problem?
I have been reading about digital signature and SSL certificates but I cannot find how it solves this problem.
Hope to find a good answer, thanks!
I am developing an express app which serves as a REST api with web client and may be future mobile clients. I am using a Oauth 2.0 token authentication for both clients. This gives a good deal of security against CSRF. I want to know How to provide security against XSS.
*I made the tokens validity period very less, requiring the client to request with refresh_tokens and other client details for access_tokens. This makes it a bit safe but not entirely*.
I am concerned with the with client_id and client_secret being stolen since its present in the front-end javascript code and it being used by other client to validate. I am thinking of using a JWT for the client authentication, will this be helpful?
Data Sanitisation is another which I am confused about. There are modules like validator, express-validator which give regex validation. According to this blog post JSON Schema validations are fast. In the REST Api JSON will used for data exchange so I was wandering why can't I use modules like tv4 or any other JSON Schema validators for data validations?? I am not asking for suggestions to use what, I just want to know the basic difference in the kind of validations each provide and specially from a point of view of XSS protection and sanitisation.
So you have three separate questions here:
1) How to protect against XSS: As long as you use JSON to share data between the client & server and use standard libraries/methods for encoding/decoding JSON, you are mostly protected. After this, you only need to worry about DOM Based XSS, which is harder to be protected. But basically you need to be careful for not using any user supplied input that can be interpreted as anything other than "string" you intended. (please visit https://www.owasp.org/index.php/DOM_Based_XSS for more information)
2) client_id and client_secret being stolen: This does not seem to be possible in the way you require. In your scenario (where you distribute clientid&secret in javascript code) there is no way on server side to know whether the request is coming from your client or a fake one.
3) Data Sanitisation: I see two levels of sanitisation in the libraries you & blogpost mentioned. validator or express-validator is mostly used to validate individual data fields. Whereas others can validate a JSON object structure in addition to what "validator" does. If you require all exchanged data is in JSON format (as suggested for XSS protection as well) then you can use json object validators like tv4. (the only drawback of tv4 seems to be allowing latest json spec, which should not be a problem for you)
BTW: It would be easier if you specified your client application is purely client-side javascript (angularjs). I could not understand your question until I found this info in comments.
I have developed Restful Authentication System same as your case with NodeJS, MongoDB, ExpressJS in order to provide flexible authentication system for multiple clients like web, mobile. Let me summarize you the important points.
I have used html5 localstorage to keep user token after first time login by using login form. When user click login button, username and password sent to server and validated. After successfull validation, unique access token sent to client and stroed in local sotrage. If you have vulnerability on your client application, anyone can get your access token and make request by using your token. In order to prevent this, you need to use ssl connection for your app. This problem does not exists only restful auth systems, this can be happen in server side session storage. Let me explain this. I am using PHP for session. When user logs in, user session saved in to temp file on server and that session id sent to client browser. Somehow, if I can get that id, I can make request with header that contains someone's session id. When you compare, restful auth seems more flexible to me. I suggest you to ;
Use SSL connection prevent your access_token from to be stolen
Generate access token with powerfull encryption methods(SHA-256)
Small expire time for access_token the better
Implement a middleware for token validation for backend service usage. I mean make your requests like;
/use/update/{userid}
with custom headers contains your user token.
Design 5 attempt failed system for your backend. If user cannot success at 5 time try, this means someone tries to send random tokens in order to get in to system. Detect and block that IP
You can also deny requests other than browser clients.
Those are the informations that I have learnt while implementing the project.
Let's say I have 2 servers (server and authenticator), and I have a client. My end goal here is to be able to identify the client on server. My solution was to come up with a token/secret system like OAuth: client has a token and secret. It passes it to server. Server passes it to authenticator. If valid, server allows the request.
Obviously, this is nonoptimal just for the number of requests being made. The reason authenticator and server are separated is because this is for a decentralised service-- any number of servers may be used, and it's impractical to ask client libraries to register on each server.
So, the question remains, what's the best/correct way to do this? The goal is to create a system that is decentralised, but can still have clients identify themselves in a relatively secure fashion to the server.
Disclaimer: I'm not a security expert so I could be off-base here and in actual implementation there seems to be a number of security issues that would need to be ironed out.
In the broadest sense, could you have the client supply credentials to the authenticator and then upon verification the authenticator supplies the client and the server both with matching security tokens and then the client and server can communicate directly?
Just curious about there a reason you don't want to implement OAuth and run your own OAuth server.
Additional reference: http://groups.google.com/group/37signals-api/msg/aeb0c8bf67a224cc
Turns out the solution was to define my problem a bit better. As I'm only trying to create a way to block applications, I only need to store their name and key when they request the server. Then, as long as they're not blocked and the key matches the one in the datastore, they'll be identified. So I'm not trying to authenticate so much as identify. Thanks for the input!