Using passport for api authentication for a mobile app. The app devs were quick to complain about the size of the access_token provided (1071 characters) and having to pass it in each request.
On investigation the bulk of the token is the signature portion. By default passport is generating a 4096bit rsa key. I found i can reduce the token size to 559 characters by generating a 1024bit key instead. Better, but still much larger than keys generated by other services like Facebook.
I can not find much info on the subject, Is it a moot point? Is 1KB token nothing to complain about? Is reducing the key size a bad idea? Anything else that can be done to reduce the size?
Update:
We have decided to continue without any changes to the key size.
try this for shorter access token:
php artisan passport:keys --length=512 --force
Related
i'm using Larave 5.4 passport to create SPA application. However, i was able to make authentication work. but access token are always short-lived tokens with 600s expiration time.
i could not increase expiration time with:
Passport::tokensExpireIn(Carbon::now()->addDays(15));
Passport::refreshTokensExpireIn(Carbon::now()->addDays(30));
it have no effect at all.
any help? thanks in advance.
Personal access tokens are always long-lived. Their lifetime is not modified when using the tokensExpireIn or refreshTokensExpireIn methods - as explained in Laravel's official documentation (https://laravel.com/docs/5.7/passport#personal-access-tokens).
The option of editing PassportServiceProvider.php in the vendor directory is a bad idea. Every time, you make an update (e.g composer update/install) or by another developer in production, code will be reverted to status quo, and it would start failing.
A better approach is to use Password Grant Tokens. The OAuth2 password grant allows your other first-party clients, such as a mobile application, to obtain an access token using an e-mail address / username and password. This allows you to issue access tokens securely to your first-party clients without requiring your users to go through the entire OAuth2 authorization code redirect flow. Be sure that you have duly installed passport (See Guide: https://laravel.com/docs/5.7/passport#installation), then run this command
php artisan passport:client --password
Having done this, you can request an access token by issuing a POST request to /oauth/token. Remember, this route is already registered by the Passport::routes method so there is no need to define it manually. If the request is successful, you will receive an access_token and refresh_token in the JSON response from the server. See payload sample below:
{
"grant_type" : "password",
"client_id":"your-client-id",
"client_secret":"your-client-secret",
"username":"twady77#gmail.com",
"password":"123456",
"scope":""
}
Sample response:
{
"token_type":"Bearer",
"expires_in":1296000,
"access_token":"eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsImp0aSI6IjVkMWJjN2NhOTU0ZWU2YTZmOGNkMGEyOTFjOTI5YzU4Zjk3ODk3M2YxZDJmNjQ2NjkyZjhjODQyZjYxNTBjZGRiYzMwY2RjMzRmZjJhYmU1In0.eyJhdWQiOiI4IiwianRpIjoiNWQxYmM3Y2E5NTRlZTZhNmY4Y2QwYTI5MWM5MjljNThmOTc4OTczZjFkMmY2NDY2OTJmOGM4NDJmNjE1MGNkZGJjMzBjZGMzNGZmMmFiZTUiLCJpYXQiOjE1NDkyOTI5MjcsIm5iZiI6MTU0OTI5MjkyNywiZXhwIjoxNTUwNTg4OTI3LCJzdWIiOiIxIiwic2NvcGVzIjpbXX0.cSvu30xAT-boA5zmVuxTr0TfH_5MYuVWYi6NVQRbryZSswt8EAFTi5QXHH1f0O63DWnLA6VFBS2AfDe4-ryJZACDnt4gtPJOeuu1rNMZ53MU1vjxnyC8FsYz8v9vmYJsZPKqfTJpuJFYRFh7kkV7uWAmrEkuF3POnDn-GjW50f4i26lIZW5ta5j4nZQrIJCQUEzwXaQtn9H-qef3bTWAaplWaV-k7Blic-0TXXVfWa_CdoKCAzHROVBRWY1Idhe1LJkvGKldUGzUfliiB1x7EVVInq94VYEP5d9__90Z2UMUn5dCEgWkXvcEHYy87_4OSwu4TQk_f3hD82OVOEtJGgPyJqK51WqnQCBYwNtxNjqAW2oaMgpritp3G8nccUiyhkE4Pd_kj3cb2OvSNRXdDS9z-RnJb1OXUkja-4Xe_JfIWUjlTnkss18xMg89hcU_3xtBwUXBWHgffzcbNoI1oOwUL6Whekduiy8csf665v0cnzkPXISmvyGhiMseIlBEN9m9uESaJqD_g7WzbsEs7meI0CAF3230UgrI1MdYSAJMW0mMPF9EScH31a_Qpde5O233Ty6-S4NAp323Wneqs_jpGSfw81CvoI1JeY0hZccRC-MBBsQ2Ox7AM36H5L3p-ybricmT3oCcHEqhufq-ygyfqk1RufJwwRblwYPyaJE",
"refresh_token":"def50200c6b2378110190ac28d9d55f622885bb0b470a20543a6f1eefb18ed93c57b7040dc4db9444aa8853209bde9d5443a407d43fcaf1deb2e1f3f5ea3ce7431c4ec5e111bdc0cc71ca76034cd2a884441c51e4c922dddfa3f6e3a3fa8e1fbb8efe4581ce70d76590e732b3fa8b0c41a8abff4a8759f9dd1cc3ae46134fb67a8f25cd79e3229f6ee3238701ebfe0e8b0e2f14bd13c7fde3f813708a3de9928c8e992850994ca97bf61984cdb846bd0d72916312d9985472fc4293a3b3f2c55e1ef19621ef009623a6780f800ece9c8d835871dc795fda5daa43ac3fdae467e66b46e4eb73d53b8cb821522ee60979711c28c54fb2085f6000ac7e96e019ce51b9f92ea3fa2028aa0238fc3dca9c900e8dd77907782b22482f95a5e55708e5bda8c28f3732ff55e361f08447b33fe05d5646cecfb9faed462d327efdcc2a3742f46f9f825275d296b4ced25c05f3b6add68f43a2b448e4523d5410c631dc45bba"
}
Try to use this library: https://github.com/GeneaLabs/laravel-caffeine , and you can look laravel session config options
tokenExpireIn() instead of refreshTokensExpireIn() use then solve tokenExpireIn problem.
for passport grant token
Passport::tokensExpireIn(Carbon::now()->addDays(10));
Passport::refreshTokensExpireIn(Carbon::now()->addDays(15));
This is only adding 10 minutes of expiry time. Don't know how and why, but instead changing internal codes. I Changed
Passport::tokensExpireIn(Carbon::now()->addDays(10000));
Passport::refreshTokensExpireIn(Carbon::now()->addDays(12000));
Now it's adding 7 days of expiry time. Seems like addDays function adding 10000 minutes.
I have the same issue before for my application, I spent two days try to find what is the problem, The best solution that I came up with is to change the expire date directly in the PassportServiceProvider
Go to vendor/laravel/passport/src/PassportServiceProvider.php line 108
new PersonalAccessGrant, new DateInterval('P1Y')
for example to set the expire date to one week
new PersonalAccessGrant, new DateInterval('P1W')
I know this is a bad solution for fixing the issue, recently I have found the same issue on Laravel Git repo
https://github.com/laravel/passport/issues/47
Maybe I searched with the wrong keywords but I never found anything about the following scenario:
I have both an API with JWT auth (Laravel + tymon/jwt-auth) and a PHP application that should query that API protected by a JWT token.
How can I make sure that the app always is authentificated? After reading a lot of tutorials and article about JWT auth I'm left with this ideas:
using a never expiring token which is stored permanently in the consuming application. If I understand it right this could be a security concern because someone who has access to that token has access to the api as long as he want? But I don't understand why this token shouldn't be invalidated if the token has been stolen?
refresh the token on every request and invalidate the old one. This implies that the consuming application have to update the token after each request in it's storage (database would make the most sense, I guess). In my opinion this produces a lot of overhead and it doesn't prevent for jwt-auth's refresh_ttl setting.
using an additional API request (perhabs cron based?) to a refresh route to prevent the token from expiring. Again there is the jwt-auth's refresh_ttl problem I think.
I wonder why there seems to be no discussions/articles about that scenario.
Any help on that subject I would very much welcome!
You don't want your user logging in every time but you also don't want them to be logged forever.
Here are my thoughts
I have worked with 1 year tokens for comercial applications, I was using it for low level third party developers, the api concept was already overwhelming for them so I went easy on the auth thingy. Once every year their application broke and they had to reach out to get the new token, bad design but it worked.
Refreshing your token on every request will kill your performance and let attackers have a consistent way to break/predict your key, no good.
In my opinion, this is your most elegant suggestion. You could use some PWA features to accomplish that.
I would suggest increasing the refresh_ttl to 30 days and keep the ttl on one hour.
If you're using SPA or heavy js apps:
On your javascript you could do an ajax setup (or prototype or whatever your javascript framework uses for oop) and have a call to refresh whenever you get a .
If you're using just common page refresh for your apps, store you JWT on a cookie, then your application can refresh it whenever it needs and there will be no special js to make. HTTPS will take care of security.
In Braintree, When I generate a client token with a $customerId, how reliable is it to save that client token to database and re-use it later on?
I always have a user corresponding to a $customerId and it would greatly reduce the number of calls to Braintree if I could re-use the token.
Does the token ever expire? There is no mention of that in the official docs.
Thanks a lot!
Full disclosure: I work as a developer for Braintree
The client token is not intended to be reused and will be revoked if a single client token is used multiple times in a short time span. You can read more about the client token in this part of the Braintree documentation.
This was a thing before 2019.
In 2019 they changed the client token behavior so now it is granted for 24 hours and can be reused unless it was granted for specific CustomerId
https://www.braintreepayments.com/blog/changes-to-client-tokens-are-coming/
The client token is a JWT. You'll need to base64 decode, to view the authorizationFingerprint. Then, split the authorizationFingerprint using ".", as the delimiter, and base64 decode the [1] position of the resulting array, and you'll see the "exp" param.
Using JWT Auth + Laravel and Ionic for a mobile app.
I want to have the users stay logged in until they log out physically with a button. JWT has '60' (an hour) as its TTL for the token.
I know I could just increase this and be done, but I imagine there is a reason to having it only an hour by default.
There is lots of terms for refreshing tokens etc but can anyone give a quick summary of how to deal with long term tokens?
Do I set a refresh every 60 minutes, every request or is having a long TTL fine?
If you look at the jwt-auth package wiki page on authentication. There is a middleware Tymon\JWTAuth\Middleware\RefreshToken the way this works is.
This middleware will again try to parse the token from the request,
and in turn will refresh the token (thus invalidating the old one) and
return it as part of the next response. This essentially yields a
single use token flow, which reduces the window of attack if a token
is compromised, since it is only valid for the single request.
in my opinion as long as your application has fairly constant communication without long periods of inactivity ( more than your 60 min window ) this is the best way to go about keeping your token fresh.
If your not using the jwt-auth package you can still apply the logic you just need to pass back a new token in the header of your response, see the RefreshToken Middleware for an example of this.
I wrote a small webserver which currently uses basic auth over ssl. So far everything works great. Now I want (need) to switch to digest auth. But I can't figure how out to make this work with passwords that are not stored as cleartext in the database? I only have the password digest (generated using bcrypt) of my users' passwords stored. Is http digest auth possible at all?
Was just looking into this just now. First, I read through RFC 2617 - HTTP Authentication: Basic and Digest Access Authentication to get some insight into the specification and see how it can be adapted for a REST API authentication.
Ran into the same question as you did—Does digest authentication mean the server needs to store the user's password in plaintext?
This Stack Overflow answer makes it clear: No. The server doesn't store the plaintext password—it should store the hash of (username|realm|password).
That would've been fine except for one thing—the canonical spec only supports using MD5 as the hash function.
Of course you could store both the bcrypt hash and the MD5 hash but doing so only undermines the security of the bcrypt hash effectively rendering it useless (since an attacker can shift his efforts into brute forcing the MD5 hash instead).
So, I took a step back and thought, why not disregard the spec and use bcrypt on both sides as the hash function (bcrypt(username|realm|password))?
Well, aside from being purposefully slow, bcrypt has a maximum password length which makes it unsuitable for use as a general digest algorithm.
Whew, by now my head was swimming but I still thought to give it another go. Some of the suggestions were to use TLS with SRP or authenticated encryption, specifically EAX, but I felt that maybe those were taking things just a step too far for a simple Web service.
To put it simply, if you're really bent on doing this you can work around bcrypt's character limitation by using a preliminary hash.
Long story short it seems that you can do:
bcrypt(sha256(username|realm|password))
And use that in place of H(A1) in a bastardized version of the spec.
The question now becomes—was all that added complexity really worth it? Did we get any added layer of security over Basic auth over HTTPS?
The question now becomes—was all that added complexity really worth it? Did we get any added layer of security over Basic auth over HTTPS?
I can see one, when you use basic auth, your HTTP client sends the Authorization header as a base64(password)
So, if you leave your web browser open, and someone opens the browser web console, he can base64 decode your password.
Whereas, with digest auth, the Authorization header is a md5 hash (and a nonce hash is included to prevent replay attacks)