I've been using Charles to debug the communication between a mobile app and an API.
We are now changing both the client (app) and the server to use JSON Web Tokens (JWT).
Is there a way to configure Charles so that the JWT is decoded when browsing the requests ?
Basically, the request (from mobile app to server) will consist of a single header (Authorization) containing the JWT, and when I click on that request in Charles, I'd like to see:
- the original token
- the decoded header
- the decoded payload
Looking at Charles' documentation, I found the following:
- Rewrite tool: could replace the token with the decoded data, but it doesn't seem like functions (base64decode) are supported, only plain text or and regexp replacement.
- Map Remote tool: seems like it could do the job, by calling a script on a server which takes in the original request as an argument, and returns the new request with the decoded data. The documentation describes a use for replacing specific sources (when browsing a website), so I'm having a hard time seeing how it could be applied to this case (client to API communication). Doesn't seem like it can pass the original request as an argument (just replaces it).
I know that I could always copy paste the token in a tool that decodes JWT, but that's a small step that I will be repeating a hundred/thousands of times, so I'd like to avoid it.
Or is there another way to debug HTTP requests between mobile and server that are encoded in JWT format ?
Since Charles Proxy doesn't support JWT Decode feature, you can try out Proxyman, which automatically decode JWT and display in a nice place.
If you need to manipulate it, you can take a look at JWT Decode Addon . The Scripting feature allows you to write JS code to achieve the same result.
Disclaimer: I'm a creator of Proxyman. Hope this answer could help you.
Related
I am resolving user data using firebase for auth like so:
from firebase_admin import auth
decoded_token = auth.verify_id_token(client_id_token)
I am initializing my firebase creds with firebase_admin.initialize_app(cred)
Here cliend_id_token is a token that the client sends. However, this takes around 1 second to perform, which seems way too long. One possibility is to use a caching layer above this (lru cache, memcache) but it still seems that it should not fundamentally take so long. Looking at the the signature of verify_id_token there does not seem to be anything that stands out as something that I can pass in:
def verify_id_token(id_token, app=None):
Any thoughts on how to diagnose (or if I am missing something)?
The problem is because that function does an http request in order to have the key to decode the jwt. In addition, because it returns info such as the email of the user, while the jwt contains only the uid as sub field of the decoded jwt, I think that it does another http request under the hood to get the user from the decoded uid.
You should implement your custom decode function, following the docs: https://firebase.google.com/docs/auth/admin/verify-id-tokens
I'm having the same issue. It's about 200ms for me (I'm using fastapi). #EuberDeveloper - glad to hear it's the same on node js - you saved me from testing it out.
I wanted to mention how I got my setup working faster in case anyone would benefit.
I've got Google API gateway with Firebase security defined in the swagger spec in front of a Cloud Run instance. API gateway validates the jwt (as per the swagger spec) and passes on the authorization header to the backend as a renamed header (from memory it's X-FORWARDED-AUTHORIZATION but best to double check). This is pretty fast.
Then in the backend you don't need to validate the id token since it'll already be validated by the time the request gets there. And if you send the UID along in the request to your backend as well as the idtoken in the authorization header, you can fetch users with the UID field you send. This removed that 200ms it was costing me to decode the id token.
Note - if you want to do things like check how old a refresh token is and revoke it for some reason then you'll still need to decode the id token.
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.
Is it safe to put a jwt (json web token) into the url as a query parameter of a GET request?
It can be safe under the following circumstances:
the JWT is one-time time usage only
the jti and exp claims are present in the token
the receiver properly implements replay protection using jti and exp
but in case it is used as a token that can repeatedly be used e.g. against an API then supplying it as a query parameter is less preferred since it may end up in logs and system process information, available to others that have access to the server or client system. In that case would be better to present it as part of a header or a POST parameter.
Besides that, by using it in the query parameters you may run in to URL size limitations on browsers or servers; using it in a header provides some more space, using it as a POST parameter would work best.
Is it safe to put a jwt (json web token) into the url as a query parameter of a GET request?
Yes, insofar that a JSON Web Token (JWT) is encoded in a way that it is transparent with the encoding of a query parameter in an URL:
A JWT is URL-encoding-safe. There will be no data-loss when used in-place; no additional encoding is required; it is even URL encoding safe inherently, applying url-encoding (percentage-encoding) on the JWT multiple times will not destroy it.
This safety is limited:
There can be a data-leak when used in-place if the URL itself is part of such a data-leak. By how URLs are commonly in use, you should treat any JWT in an URL query parameter as-if the data-leak already happened and therefore prepared the JWT for it already (e.g. prevent replay attacks).
And it will be at best as safe as the transport of the URL information is, and never more safe.
And if the transport of the URL information is not safe, everything in the URL can never be more safe either, which includes the JWT when used as a GET parameter.
Apart from using it in an URL (which looks to me as a mechanism of transport), you may want to consider additional data-retention, protocol and even your own systems properties, including those of the JWT in question itself.
For all these it depends.
For some of those considerations, please see the other answer and JSON Web Token (JWT) - RFC-7519 incl. the referenced updates there.
I want to secure my application using access token while communicating to the server.I am using nginx server which logs all the headers which are present in the request. It is a security threat if we are logging the header. If somebody can access the logs file. They can easily manipulate the data. Then why people use token in header?
In this case can we consider payload as the right choice?
What is the best place(or standard way) to put access token : Header or in payload?
What are the pros and cons of both?
IMHO, it is mainly a matter of taste, and of tools you use for testing ...
If you use elaborated tools, that allows you to set custom headers, header is nice, because it does not clutter the payload. But if you want to be able to test with a simple browser, if is easier to add a request parameter than a header ...
You can even accept both, first looking in the header, and then in payload if you could not find the token in header.
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.