Stripe has a state parameter that it returns back to me to verify
https://connect.stripe.com/oauth/authorize?response_type=code&client_id=ca_ABCDEFG12345&scope=read_write&redirect_uri=https://sub2.example.com&state=asdf1234
Which is great! But what if I want to get a few things back from Stripe when it returns? Can I pass multiple pieces of information to this parameter? Is the best way to do this by stringifying and object and then parsing it when it is returned?
Great question! By design you should not pass serializable data through an OAuth2 state parameter, as it leaves open a window where a malicious party could edit that data before it's returned to your application. You should use your own application's authentication state to verify your users' identity once the Stripe OAuth flow returns to your site.
It's recommended that you use 'state' as a CSRF protection, and pass any sensitive parameters through your own application:
https://stripe.com/docs/connect/reference#get-authorize
Related
I'm giving NestJS a try and am pretty happy with the results so far. Right now I'm struggling with some concepts that aren't clear enough in my head.
My API has an authorization-token in the format of a cookie (NOT A JWT). When the API receives a request, it has to use said cookie to ask another service (async), which user is sending it and what role he has.
This exchange from cookie to user info should prepend any controller logic and should be applied globally.
I think this can be done via a middleware, an interceptor or a pipe, but which of those is considered the better way according to NestJS?
Honestly, I would use a guard for this kind of feature. Check if the cookie exists, if not, there's already a problem, send back a 403 (i.e. return false). Otherwise, the rest of the logic can follow and you can attach the information to your req object, thereby having it available throughout the rest of the request. As guards are the first of the enhancers to fire, this also ensures that the value is available in interceptors and certain pipes.
I had a question regarding best practice when it comes to building a global utility class in EmberJS when the class will exhibit user-specific behavior.
The following conditions are all true:
The class's methods could be accessed from anywhere in the entire application.
The application performs JSON based authentication using Ember-Simple-Auth.
The authentication confirmation payload comes with some information about the user.
The information received in the token payload will determine the behavior of the utility class's function.
My Questions
Is a Util the best option?
Should I be using services and somehow "initialize" this service on a confirmed authentication? My end goal is to use this class from almost every route/template/component in my application.
How chill are authentication payloads? Is it OK to send crumbs of user specific information information in the authentication payload in addition to any tokens?
The best choice is using services.
They are :
singleton
could be injected to any object extended from Ember.Object
Is a Util the best option?
No. Services is best option. You can initialize it after successful authentication hook of ESA. And it could be injected everywhere
How chill are authentication payloads?
You can send anything. Your authenticator is responsible to process it. The payload is saved in data.authenticated object in ESA session service
I am using form authentication and role based access.
I want to make all the subsequent request as an authentication request using the access token.
I refer Loopback-example-access-control example, but not get a clear idea.
In this example, they pass access token using query string. My question is I want to make all the request as authenticated using access-token without pass query string or header.
Any other alternative way is available?
I need demo application that includes authentication and authorization, except loopback-example-access-control example.
Please help me, I am new to strong loop.
There are only three ways to send data to a server: path/query string, headers, and the request body. Since you don't want to use the query string (which is good, you really shouldn't) and you don't want to use a header (which is the most common and currently the industry standard) then you are left with only the request body. That's not a great choice either, and not supported by default in LoopBack, you would have to code that up yourself.
The right solution here is to use the Authorization header and send the access token in there with each request.
And just to be clear, this really has nothing to do with LoopBack, this is just token-based authentication basics. You must pass the token with each request, that's how the system works, there is no alternative.
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.
In the sample Java code for Google+ server-side authentication there is this comment within the code for handling requests to the url /connect:
// Normally the state would be a one-time use token, however in our
// simple case, we want a user to be able to connect and disconnect
// without reloading the page. Thus, for demonstration, we don't
// implement this best practice.
//request.session().removeAttribute("state");
The state attribute is a random sequence generated on the page load of the default route (/) and must be presented by the ajax call to /connect for the connect request to succeed.
The comment implies that it is improper for the state to remain in the session, but has been commented out simply to allow the user to log in and out repeatedly in the example.
However, I do want the user to be able to log in and out at will, without reloading the page. If I keep the value for state in the session am I allowing an exploit? Should I be generating a new state and updating it somewhere in the DOM on /disconnect? Or should I do something different altogether?
In short, the state value set in the session is used to prevent cross-site-request-forgery (CSRF/XSRF). In the samples, we have a completely trusted path when performing the OAuth v2 flow so for that specific scenario token validation is redundant.
For more information about the state parameter you can look at:
Forming the URL (OAuth v2)
Confirm anti-forgery state token
Related question and answer here.