I was wondering how I can to make JWT with length of 235 characters small like Discord's
Thank you in advance
The length of a JWT depends on the amount of data which is in the header and payload. The more data you have in the payload, the longer the resulting token will be. So you can somewhat control the length of the token. Normally this should not be a problem for you if the token is longer or shorter.
Related
In DataPower we have a requirement to extract the “onpremisessamaccountname” from the JWT token and insert into the header “user” before sending to Backend server.
How can we do this using XSLT code or is there any possible way to achieve this in DataPower?
I will be grateful for any help with example
Thank You!
If you're using a AAA, I'm pretty sure there is a JWT check that will validate the signature and throw the claims into context variables.
Otherwise a JWT is mostly base64 encoded JSON so shouldn't be too difficult to decode and regex out the value you want.
Looking at typical JWT tokens I can tell the header mostly identifies the signature scheme being used. For a given web application it may be only a single signature scheme, say HS256. So the header is then merely a base64 representation of:
{"typ":"JWT","alg":"HS256"}
static content, sent back and forth between client and server.
Why do we need to send a complete JWT token having three sections header.payload.signature? From what I've tested skipping the header and only sending payload.signature parts does the job. In most cases, using a third-party JWT library would only require to prepend a stored base64 represention of the header to the token for validation, saving a few dozen bytes on each rountrip.
Are there any security issues arising from trimming the header in user-server communication? I do understand this violates the standard, but browsers don't care anyways.
HMAC-SHA2 - 256bit isn't the only option for "alg".
If it's hashed with a different algorithm, such as SHA-3, you'd need to know in order to validate the token.
I know that it was discussed widely but I can't sum on what I read.
Is it correct that JWT is put to HTTP headers without encoding? Only being signed on. So that's common practice that token data (claims) is open and only signature allows to check whether JWT is reliable. From the point of view of keeping details in secrete people rely on HTTS.
Correct?
I understand JWT is susceptible to replay attacks and according to a number blogs, the same token can be used by different servers and doesn't need to be regenerated. Does that mean the JWT is not generated with the body of the message in the payload? To be secure, I thought it would be used to sign each request but then I guess is not very efficient and a new JWT needs to be generated per message? I am a little confused. Would appreciate if someone could clarify this point. Seems unsafe if someone could steal the JWT, change the message body and reuse the same authorisation header.
Thanks!
I am working on a REST API for a web application that up until now we have developed internally for a couple of companion applications. Now that we are looking at opening up to outside developers we want to add tokens to the API in order to help identify who is making requests and in general to help manage it's use. At this point we are using https and basic authentication for user authentication on the API.
The token scheme we've been discussing would be very simple where each developer would be assigned 1 or more tokens and these tokens would be passed as a parameter with each request.
My question is if you've done something similar before how did you do it (did you do more or less, how did you handle security, etc) and do you have any recommendations?
First, you might want look at http://OAuth.net. Depending on your usecases, it might provide the security you need.
As to the token, it's a BLOB to most protocols, including OAuth. You can put any information you need in it in any format.
Here is what we do,
First we assign each developer a key with associated secret.
The token itself is an encrypted name-value pairs. We put things like username, expiry, session id, roles etc in there. It's encrypted with our own secret so no one else can make it.
For easy of use with web API, we use the URL-safe version of Base64 so the token is always URL-safe.
Hope that helps!
You might also want to think about maybe adding a time based token that would allow you to limit the amount of time a request is valid. this will help with someone trying to do a replay attack.
You would have a handshake call to get/assign a time valid token based off the above developerKey. This token would be stored locally and passed back to the caller.
The developer would then use this key in a request to validate the request and the developer.
For example that key can then be used for 5 mins or for 10 requests or whatever you define. after that point the generated time based token is removed from the valid list and can no longer be used. the developer will then have to ask for a new token.
UUID is very good for any temporary random key you fancy dishing out. Unpredictable and fast to generate, with collisions so unlikely they are effectively unique. Make nice session keys also.