I am using jwt auth for the token work in laravel. Its working fine on rest client but when I call it in web service, out of 10 times, 2 times it returns invalid_token error. When ever internet speed is fast, it starts returning invalid_token, on 2G, it is working fine. Can any one please let me know the solution?
Is their some timing issue?
Related
I am trying to implement the BFF-Gateway pattern (no tokens in the browser) to be used with a React SPA. The BFF is using AddMicrosoftIdentityWebAppAuthentication to handle login and issue a cookie to the SPA. And it is using YARP to proxy api requests to a downstream api. I'm using Azure B2C. Everything works perfectly until the BFF id_token expires in 1 hour. At that point, fetching the downstream api access token via GetAccessTokenForUserAsync (which is called in a piece of middleware) fails:
var scope = _configuration["CallApi:ScopeForAccessToken"];
var accessToken = await _tokenAcquisition.GetAccessTokenForUserAsync(new[] { scope });
ctx.Request.Headers.Add("Authorization", "Bearer " + accessToken);
Exception:
IDW10502: An MsalUiRequiredException was thrown due to a challenge for the user. See https://aka.ms/ms-id-web/ca_incremental-consent.
ResponseBody: {"error":"invalid_grant","error_description":"AADB2C90085: The service has encountered an internal error. Please reauthenticate and try again.\r\nCorrelation ID: 622d6bd6-d06e-4142-86f2-b30a7a17b3b5\r\nTimestamp: 2022-11-25 09:31:23Z\r\n"}
This is effectively the same as Call Downstream API Without The Helper Class example and this sample, except that I'm acquiring the access token in middleware, not a controller, so the downstream YARP requests contain the access token. BTW I get the same error if I do this inside a controller per this example. And I see no soluton to this in the sample.
There is a similar question here which references the sample referenced above, but for the B2C sample I see no solution to this problem.
I also found this sample and this explanation. But this uses Microsoft.Owin to configure auth, not AddMicrosoftIdentityWebAppAuthentication. This looks promising, but is a departure from most examples I see that use Microsoft.Identity.Web.
Can you please point to the correct soluton? I need call to be able to call _tokenAcquisition.GetAccessTokenForUserAsync after the id token expires without asking the user to reauthenticate and/or the SPA to having to reload.
At the moment I am handling this issue in the SPA by catching the exception from MSAL and redirecting back to the login endpoint in the BFF which initiates the challenge. This gets me a new id_token and cookie, but this is just a temp workaround as it's very disruptive to user to be redirected away from the SPA.
I have built a mobile app using React Native.
This app connects with a REST API I built using the Laravel framework.
This API is hosted on a VPS and served over HTTPS.
The mobile app works as intended where I expect it to, with the exception of the following use case:
A user has an iPhone 8+. This user’s carrier is AT&T. The 5Ge, to be specific.
This user can download the app and install it no problem.
When they open the app, the app connects to the API, and gets the data to display on the home screen.
The user can login, using their credentials, which are sent to the API, and the API returns an access token on a valid login.
Every subsequent request, is sent with an Authorization header: Bearer [token]
These requests specifically, never reach the server. All authenticated routes for the API are unreachable for this user.
Users on other networks, like Verizon and TMobile, do not have this issue.
The mobile app uses Axios library for sending HTTP requests.
A timeout of 25000 (maximum that can be sent on the iOS?) is passed as an option to the authenticated action. The action fails for this user.
The error is caught and then sent to a public route on the API, without an Authorization header in the request.
This request reaches the server and adds the error message from the request from the mobile app, to the error log on my server.
When I inspect the error that was thrown by the authenticated action failure, it reads “Network error” with a code of 0.
If the timeout is set lower, at 15000, the error thrown by the failed authenticated action is a timeout error, exceeded 15000.
I have contacted AT&T today, and they said we should contact Apple.
After they patched us through to Apple, Apple said issue sounds like it is a cell tower issue, and offered to run diagnostics on the phone.
My question is: Why are the requests that contain an Authorization header Bearer token not able to reach my server when the user is on the AT&T network. Is the bearer token making the request bulky and slowing down the request to where our towers aren’t able to send it?
Or does AT&T have some kind of middleware that would trash the request for some reason?
Could the Authorization header cause AT&T to handle the request differently and send it some other way and in this way could DNS errors cause the request to fail in this way.
Please help, I hope I have explained it well enough.
Edit: Laravel Passport generates access_token for the authenticated API that is 1000+ characters in length. It looks like I can reduce that by about half. I am going to try that next.
I'm finding this is resolved now.
I did two things. I reset my Laravel Passport keys with a specified --length of 1024.
This resulted in my access tokens being around 557 characters long instead of 1000+
I also made some DNS changes in my subdomain. A scan I did showed a nameserver parent mismatch error between the subdomain and parent domain. I made the changes and got those warnings to go away.
These are the things I did. My two app users who are with the AT&T network carrier tested the app tonight after I did these changes.
They logged in. Opened the timeclock. Clocked in. And that request made it to my server like it was supposed to, with the new shorter access token.
I don't know which one of those two things fixed this issue. But I would probably guess it was the DNS problems that I resolved. I still find it odd that the issue only occured on the AT&T network when with an Authorization token in the header of the request.
I am using Laravel 5.8 with Passport 7.2 for building API for my application. I am using password_grant for authentication.
I have created everything from registration to login and everything seems to function properly. I am able to get access_token and refresh_token and to access routes that has middleware auth:api attached.
In my routes i have this:
Route::group(['middleware' => ['auth:api']], function () {
...
Route::get('test', function (Request $request) {
return $request->user();
});
...
});
When i call this /api/test URL with header Authorization: Bearer access_token i am getting currently authenticated user. That just works fine.
I am testing these endpoints with Postman, but everything is same if i test this using javascript from browser.
The problem is when i have two different access_token from two different users. If i call this URL with one access_token i get correct user data as response and if i wait for few seconds and call same URL with second access_token i get correct second user data as response. But if i call this URL two times with these two access_tokens at same time (call first and for example after half second call second) i get first call user data as response in both requests.
I hope you can understand what is problem.
Could this be caching problem, or maybe session problem (even if api is stateless)?
If you need more informations just tell me.
Firstly i thought it was browser cache issue, but it is same in postman. I have also tried to use Google Chrome for one request and Mozilla for second and everything is same.
If you have any idea about what could be wrong i will appreciate it :D
I have found a solution. It is not Laravel or Passport problem.
The problem was:
on my server we have Nginx and https://engintron.com/ configured and this Engintron has some micro-caching mechanism.
This micro-cache could be completely disabled or can be disabled with headers in request (Cache-Control: private).
Micro-cache is caching GET request to URL for 1 second and ignoring different Authorization headers. That's why i get same user data for two different Authorization headers if i make these two requests in under 1 second period.
I hope this will help someone else in future. If somebody need more info do not hesitate to contact me :D
I am using jwt auth for the token work in laravel. Its working fine on rest client but when I call it in web service, out of 10 times, 2 times it returns invalid_token error. When ever internet speed is fast, it starts returning invalid_token, on 2G, it is working fine. Can any one please let me know the solution?
Is their some timing issue?
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.