I'm generating a token on our auth server (Node.js) in node-jsonwebtoken that will be passed to an API (PHP Laravel) and verified by tymondesigns/jwt-auth.
A token generated by tymondesigns/jwt-auth will be verified successfully by
its own verify function, node-jsonwebtoken and jwt.io.
A token generated by node-jsonwebtoken will be verified successfully by its own verify function, jwt.io, but not tymondesigns/jwt-auth.
On the Laravel server, i get the following error when I try to verify a token generated by node-jsonwebtoken:
TokenInvalidException in NamshiAdapter.php line 71:
Token Signature could not be verified.
The payloads look identical when I look at them over at jwt.io. I have even tried to generate the exact same token on the Node server by passing the same iat,sub,iss,exp,nbf and jti as generated by a working token, but tymondesigns/jwt-auth still won't accept it.
Is there anything else that could be causing this, but isn't visible in the decoded information? I'm also not 100% sure how jti works. Maybe there is something preventing this from working about that?
node-jsonwebtoken (7.1.9), tymon/jwt-auth (0.5.9), namshi/jose (5.0.2)
The last version of the namshi/jose library is 7.0.
There is also a known bugs for all ESxxx algorithms.
If you cannot verify signatures using that library, you could try with another one.
I developed a library that supports all features described in the RFCs related to the JWT, including encryption support.
The reason is, as mentioned by Spomky aswell, a bug in namshi/jose related to the iss claim. It is resolved in 7.0 which is used by tymon/jwt-auth 1.0.0-alpha.2. However, since there currently isn't a documented way to install 1.0.0-alpha.2, we probably have to wait for a stable release.
Until then, since the problem and the bug is related to the iss claim, removing the iss requirement from required_claims and generating the tokens without it solves the problem temporarily.
In my case I had a url inside the payload. PHP escapes slashes by default when encoding to JSON, while Node.js doesn't. When the verification JWT gets generated in PHP (with those extra backslashes) of course the final hashes won't match since the payload is just different. Solution is to use the JSON_UNESCAPED_SLASHES flag when converting to JSON inside your JWT library, I was using https://github.com/namshi/jose so I created a simple class like this one:
use Namshi\JOSE\SimpleJWS;
class SimpleJWSWithEncodeOptions extends SimpleJWS
{
protected static $encodeOptions = 0;
public static function setEncodeOptions($options)
{
self::$encodeOptions = $options;
}
/**
* Generates the signed input for the current JWT.
*
* #return string
*/
public function generateSigninInput()
{
$base64payload = $this->encoder->encode(json_encode($this->getPayload(), self::$encodeOptions));
$base64header = $this->encoder->encode(json_encode($this->getHeader(), self::$encodeOptions));
return sprintf("%s.%s", $base64header, $base64payload);
}
}
Then it could be used like:
SimpleJWSWithEncodeOptions::setEncodeOptions(JSON_UNESCAPED_SLASHES);
$jws = SimpleJWSWithEncodeOptions::load($token);
$jws->verify($key);
$data = $jws->getPayload();
This problem was very specific to my payload content but it could help someone
Related
Issue
I am trying to use a yubikey for second factor authentication via their OTP Validation Protocol Version 2.0. Despite following all the documentation meticulously (https://developers.yubico.com/OTP/OTP_Walk-Through.html and https://developers.yubico.com/OTP/Specifications/OTP_validation_protocol.html), I either get a BAD_SIGNATURE or MISSING_PARAMETER status response. I was trying to attach an HMAC-SHA-1 signature only because of the MISSING_PARAMETER response (the signature is not required). When I do try to attach a HMAC-SHA-1 signature then I get the BAD_SIGNATURE status response.
Environment
I am using Visual Studio 2019 and ASP.NET via a custom login form for authentication. Because of the deadline I am attempting to use SharePoint 2019 as a platform since it meets all the requirements OOTB except the 2FA requirement. Since there were issues in the past with AD based authentication I am using Forms auth with ASP.NET Sql Membership as a provider.
Login Code Process
The custom login form first checks the membership provider without setting any auth cookies. If the username and password are valid it proceeds to check if the user requires 2FA via yubikey. If they do I am using an HttpWebRequest to send the get and then reading the response from it (for debugging I am currently printing the response on a label):
string getUrl = "https://api2.yubico.com/wsapi/2.0/verify?id="+YUBICOID+"&otp="+otp+"&nonce="+nonce;
HttpWebRequest yubiGet = (HttpWebRequest)WebRequest.Create(getUrl);
HttpWebResponse response = (HttpWebResponse)yubiGet.GetResponse();
Stream respstr = response.GetResponseStream();
StringBuilder sb = new StringBuilder();
string temp = null;
int ct = 0;
byte[] buffer = new byte[8192];
do
{
ct = respstr.Read(buffer, 0, buffer.Length);
if (ct != 0)
{
temp = Encoding.ASCII.GetString(buffer, 0, ct);
sb.Append(temp);
}
}
while (ct > 0);
string responseStr = sb.ToString();
ErrorLabel.Text = "get: "+getUrl+ "<br /><br />response: " + responseStr;
Per the documentation (see the validation protocol link above) the HMAC signature is not required, however when I leave it off I get the MISSING_PARAMETER response. To build the signature I followed the documentation and reviewed the code in the old YubicoClient class (deprecated). I used the same function calls and processes to generate the signature.
If the username and the creds were verified (via membership provider) and 2FA (yubikey) passed then I set the auth cookie and redirect appropriately.
What I have tried
Everything works except the yubikey response part. I have tried including all of the parameters indicated in the validation protocol documentation, both with and without the signature. With the signature I receive a BAD_SIGNATURE response and without it I receive a MISSING_PARAMETER response.
I am using the Client ID from the Yubico API Key signup from https://upgrade.yubico.com/getapikey/ site for the id url parameter. When I tried with the signature I used the secret key that was generated there. I followed the same process to generate the signature that is used in the YubicoClient class (deprecated)
A separate page is used to link the users to the key and is outside the scope of this issue.
I did use the yubikey manager application to reset the slot and re-registered it with the api key signup multiple times, using both slot 1 and slot 2 on the key.
It is a Yubikey 4 C FIPS. If it works we will be getting a lot of yubikey 5's. The documentation does not differentiate key generations and the yubikey manager indicates that the OTP is supported and there are no issues generating the otp.
Any guidance is greatly appreciated!
Ok. Figured it out. Reduced nonce characters from 40 to 20 and it worked. The documentation stated "from 16 to 40 character long string" I was using a random number generator to get bytes and then converting to string. Not sure if it was the url length or if the generated nonce resulted in more than 40 characters, but when I reduced it from 40 to 20 bytes it worked. I am happy now!
Firebase ID token has invalid signature
Hi all, I'm somehow new to NodeJS and I've only used Google Firebase a few times.
Now, I'm trying to verify an idToken generated using getIdToken() method whenever a user signs up or signs in. The token generation works fine but if I try to use this token to authorize a user admin.auth().verifyIdToken(idToken) on another route, I get this error Firebase ID token has invalid signature on Postman. I tried to verify the token on jwt.io as well, it gave error Invalid Signature.
I tried switching to different algorithms, some eventually made the token valid on jwt, but there is usually a VERIFY SIGNATURE box by the bottom-right which I don't really know what to fill there. Well, I've tried copying different newly generated valid tokens by jwt after changing algorithm, but I still get Firebase ID token has invalid signature from Postman.
Does anyone know what the problem may be? Please help.
The problem comes from the Firebase Emulator Auth. The Firebase-hosted Auth is unable to verify JWT token generated by the Firebase Emulator Auth.
To verify the token manually on jwt.io, you need to grab one of the public keys from google: https://www.googleapis.com/robot/v1/metadata/x509/securetoken#system.gserviceaccount.com
To choose the correct key, find the one that corresponds to your kid from jwt.io.
Paste in the correct corresponding value and now your token should verify correctly (be sure to clear out any \n characters):
For easier programmatic verification, the "JWK URI" is https://www.googleapis.com/service_accounts/v1/jwk/securetoken#system.gserviceaccount.com
Source: https://firebase.google.com/docs/auth/admin/verify-id-tokens
For some reason, verifyIdToken function throws "Firebase ID token has invalid signature" each time for valid tokens when used in Firebase Emulator locally. I fixed this problem by starting using firebase hosted auth instead of emulator auth (remove auth property from firebase.json). Also, I reported the bug to Firebase.
I agree with Genius Hawlah's answer, the problem is the Firebase Emulator Auth. As a workaround I suggest to start emulators without the Auth one with the --only flag, for example firebase emulators:start --only firestore,functions, and authenticate with a user you have in the production Authentication
TLDR;
Prefer log from dart:developer over print and debugPrint.
I was not using the emulator...
I'm new to Firebase and have experienced this, and even upvoted GeniusHawlah's as Taras Mazurkevych's answers... But couldn't find anything in the Firebase setup related to the simulator that I did.
So it happened I was testing my firebase using a truncated JWT token, printed from Dart's debugPrint (which limits truncates output). I was successful in using log from dart:developer!
I was enlightened by https://github.com/flutter/flutter/issues/22665#issuecomment-456858672.
I encountered a similar problem, figured out that by BE was pointing to the local emulator, but FE was pointing to the remote Firebase Auth (because of a bug in the code firebase.auth().useEmulator(...) wasn't called)
As you can see in the source code, the firebase-admin package behaves differently when there is an Auth emulator available. You can either not start it to begin with or make it undiscoverable by removing its address from process.env.
delete process.env.FIREBASE_AUTH_EMULATOR_HOST
Source reference:
public verifyIdToken(idToken: string, checkRevoked = false): Promise<DecodedIdToken> {
const isEmulator = useEmulator();
return this.idTokenVerifier.verifyJWT(idToken, isEmulator)
.then((decodedIdToken: DecodedIdToken) => {
// Whether to check if the token was revoked.
if (checkRevoked || isEmulator) {
return this.verifyDecodedJWTNotRevokedOrDisabled(
decodedIdToken,
AuthClientErrorCode.ID_TOKEN_REVOKED);
}
return decodedIdToken;
});
}
emragins answer is great!
One thing which emragins wrote but it wasn't clear for me is that you need to copy the whole text between
-----BEGIN CERTIFICATE-----
-----END CERTIFICATE-----\n
and made replace("\n","").
The result from this operation you can paste to the JTW.io. VERIFY SIGNATURE field.
recently in one of my applications I needed to access currently logged-in user data for saving in another model (something like the author of a book or owner of a book). in my googling, I encountered these references but none of them was useful.
https://github.com/strongloop/loopback/issues/1495
https://docs.strongloop.com/display/public/LB/Using+current+context
...
all of them have this problem about accessing context or req object. after three days I decided to switch to afterRemote remote hook and add Owner or Author on that stage.
but something was wrong with this solution.
in strongloop's documentations (https://docs.strongloop.com/display/public/LB/Remote+hooks) there is a variable as ctx.req.accessToken that saves current logged-in user access token. but in the application this variable is undefined.
instead, I found accessToken in ctx.req.query.access_token and it was currently access_token variable that is sent to the server.
here is my problem:
is this variable (ctx.req.query.access_token) always available or
it's just because loopback-explorer send access_token as GET
variable?
in production mode do applications need to send access_token as
GET variable or it should be sent as Authorization in the header?
why ctx.req.accessToken is undefined?
could these things change over time? cause most of users encounter this problem due to deprecation of app.getCurrentContext()
Is this variable (ctx.req.query.access_token) always available or
it's just because loopback-explorer send access_token as GET
variable?
Well if your application always sends in the querystring, then it'll be always available for you, but it also sent in the header, or cookie or in the request body, but I don't suggest using it because it if the user logged in and the access token is valid and ctx.req.accessToken should be available and you can use it.
In production mode do applications need to send access_token as
GET variable or it should be sent as Authorization in the header?
I believe Authorization header is preferred, as if you send it in a GET variable, well it'll be visible in the logs and someone with the access to the logs can access the session(well unless you trust everyone), other than this it's fine to have it in a GET variable. Though I believe loopback client SDKs(Angular, Android, iOS) all send it via Authorization header by default, so you might have to configure them(maybe not possible).
Why ctx.req.accessToken is undefined?
Sometimes the context is lost thanks to the database drivers connection pooling, or the context req is lost(ctx.req) and they are null.
Assuming ctx.req is defined(because sometimes it's not), then probably that means the user is not logged it, or it's access token wasn't valid(expired or not in database). Also it could be a bug(maybe misconfiguration on your side), which also means for you that you will authentication problems.
Could these things change over time? cause most of users encounter this problem due to deprecation of app.getCurrentContext()
app.getCurrentContext is risky to use and I don't suggest unless you have no other solution. If you use it and it works, it might stop working if the database driver changes or in some corner cases that you haven't tested it, it might not work.
In the updated doc https://loopback.io/doc/en/lb3/Using-current-context.html
add this in your remoting metadata
"accepts": [
{"arg": "options", "type": "object", "http": "optionsFromRequest"}
]
then
MyModel.methodName = function(options) {
const token = options && options.accessToken;
const userId = token.userId
}
but it says
In LoopBack 2.x, this feature is disabled by default for compatibility reasons. To enable, add "injectOptionsFromRemoteContext": true to your model JSON file.
so add "injectOptionsFromRemoteContext": true on your model.json file
I am creating an ASP.NET MVC5 action method that implements a password reset endpoint and accepts a click-through from an email message containing a token. My implementation uses OWIN middleware and closely resembles the ASP.NET Identity 2.1 samples application.
As per the samples application, the token is generated by UserManager and embedded into a URL that is sent to the user by email:
var token = await UserManager.GeneratePasswordResetTokenAsync(user.Id);
var encoded = HttpServerUtility.UrlTokenEncode(Encoding.UTF8.GetBytes(token));
var uri = new Uri(Url.Link("ResetPasswordRoute", new { id = user.Id, token = encoded }));
The link in the email message targets an MVC endpoint that accepts the token parameter as one of its route segments:
[Route("reset-password/{id}/{token}"]
public async Task<ActionResult> PasswordResetAsync(int id, string token)
{
token = Encoding.UTF8.GetString(HttpServerUtility.UrlTokenDecode(token));
// Implementation here
}
However, requests to this endpoint (using a URL generated in the above manner) fail with Bad Request - Invalid URL.
It appears that this failure occurs because the URL is too long. Specifically, if I truncate the token segment, it connects correctly to the MVC endpoint (although, of course, the token parameter is no longer valid). Specifically, the following truncated URL works ...
http://localhost:53717/account/reset-password/5/QVFBQUFOQ01uZDhCRmRFUmpIb0F3RS9DbCtzQkFBQUFzcko5MEJnYWlrR1RydnVoY2ZwNEpnQUFBQUFDQUFBQUFBQVFaZ0FBQUFFQUFDQUFBQUNVeGZZMzd4OTQ3cE03WWxCakIwRTl4NkVSem1Za2ZUc1JxR2pwYnJSbmJ3QUFBQUFPZ0FBQUFBSUFBQ0FBQUFEcEpnVXFXS0dyM2ZPL2dQcWR1K2x6SkgxN25UVjdMYlE2UCtVRG4rcXBjU0FBQUFE
... but it will fail if one additional character is added ...
http://localhost:53717/account/reset-password/5/QVFBQUFOQ01uZDhCRmRFUmpIb0F3RS9DbCtzQkFBQUFzcko5MEJnYWlrR1RydnVoY2ZwNEpnQUFBQUFDQUFBQUFBQVFaZ0FBQUFFQUFDQUFBQUNVeGZZMzd4OTQ3cE03WWxCakIwRTl4NkVSem1Za2ZUc1JxR2pwYnJSbmJ3QUFBQUFPZ0FBQUFBSUFBQ0FBQUFEcEpnVXFXS0dyM2ZPL2dQcWR1K2x6SkgxN25UVjdMYlE2UCtVRG4rcXBjU0FBQUFEf
I believe that the default IIS configuration setting for maxUrlLength should be compatible with what I am trying to do, but I have also tried explicitly setting it to a larger value, which did not solve the problem.
However, using Fiddler to examine the server response, I can see that the working URL generates a server response with the following header ...
Server: Microsoft-IIS/8.0
... whereas the longer URL is rejected with a response containing the following header ...
Server: Microsoft-HTTPAPI/2.0
This seems to imply that the URL is not being being rejected by IIS, but by a middleware component.
So, I am wondering what that component might be and how I might work around its effect.
Any suggestions please?
Many thanks,
Tim
Note: Although my implementation above Base64 encodes the token before using it in the URL, I have also experimented with the simpler approach used in the sample code, which relies on the URL encoding provided by UrlHelper.RouteUrl. Both techniques suffer from the same issue.
You should not be passing such long values in the application path of the URL as they are limited in length to something like 255 characters.
A slightly better alternative is to use a query string parameter instead:
http://localhost:53717/account/reset-password/5?token=QVFBQUFOQ01uZDhCRmRFUmpIb0F3RS9DbCtzQkFBQUFzcko5MEJnYWlrR1RydnVoY2ZwNEpnQUFBQUFDQUFBQUFBQVFaZ0FBQUFFQUFDQUFBQUNVeGZZMzd4OTQ3cE03WWxCakIwRTl4NkVSem1Za2ZUc1JxR2pwYnJSbmJ3QUFBQUFPZ0FBQUFBSUFBQ0FBQUFEcEpnVXFXS0dyM2ZPL2dQcWR1K2x6SkgxN25UVjdMYlE2UCtVRG4rcXBjU0FBQUFEf
That should be safe for at least 2000 characters (full URL) depending on the browser and IIS settings.
A more secure and scalable approach is to pass a token inside an HTTP header.
I'm building a client for an api that uses http digest access authentication for authentication. I have studied the rfc to know the setup the required response headers and this works well on my emulator. Problem however is when I test on my phone (nokia E5), I found out that getting the www-authenticate header from the returned headers doesnt get the full value
[code]
// c = (HttpConnection) Connector.open(url) and other declarations
String digest = c.getHeaderField("WWW-Authenticate");
System.out.println(digest); // gives only: Digest
//no realm, qop and others
[/code]
I'm I doing something wrong or it is from the phone? What are my other options?
I have faced this problem in some nokias, and yes, it is a bogus HttpConnection implementation ... I suggest you to try creating a new header from the server side with a base64 encoded WWW-Authenticate-encoded header and using it instead, or you can do it the hard way and implement the whole HttpConnection from scratch ...