I have an application hosted in Azure using Azure Active Directory and OpenIDConnect for authentication - generally all works well. However I'm having an issue where some requests generate a call to https://login.microsoftonline.com/ and then on to the requested page - no password is requested. I'm assuming that this is some kind of token refresh?
The problem is that the site uses a fair amount of ajax and these requests stop working because they get redirected to https://login.microsoftonline.com/ This happens after maybe 15 minutes, however the nbf and exp properties of the JWT token show a validity period of approximately an hour.
I've set the BackchannelTimeout property of OpenIdConnectAuthenticationOptions to 30 minutes, however this doesn't seem to have made any difference.
Can anyone offer any advice on what may be happening and the options to change or work around the behaviour?
Your question can be answered in the same way as this other thread: MVC AD Azure Refresh Token via ADAL JavaScript Ajax and KnockoutJs
In short: the OpenId Connect middleware is designed to support redirect based web applications. Ajax calls are not well suited to be protected via cookies, and the issue you are experiencing is one of the reasons why. Javascript based API calls are better protected using tokens rather than cookies.
For some links that might provide an alternative approach, see the link above.
I created a nuget package for .NET web applications which is refreshing the Azure Active Directory Token in the background.
More info: https://www.nuget.org/packages/RefreshTokenForAjaxRequest.Azure.ActiveDirectory/
Related
I have two or more back-end API(Laravel) projects and a single front-end React JS project. From the front-end app, I will call all of the back-end API projects.
When the user login, authentication will check in App 1(with Laravel passport) and return access_token.
I want to use these access_token when calling API from both App 1 and App 2. But, the main problem is how to check access_token validation from App 2 to App 1 server.
To solve this problem, I think but not sure it is the correct way or not, I can create middleware in the App 2 server and get every incoming access_token and send it to check validation to App 1. If return true, user can access, else can't access.
But, I think this way is inappropriate because every incoming request needs to check access_token validation from App 2 to App 1, it will slow down the server and bottleneck problem.
I already search a lot of posts on google but, not yet find the best way for me. I found one way OAuth server implementation https://www.youtube.com/watch?v=K7RfBgoeg48 but, I think that way is not working well in my project structures because I have a lot of customization.
I'm also read the discussion on reddit(https://www.reddit.com/r/laravel/comments/dqve4z/same_login_across_multiple_laravel_instances/) but, I still didn't understand very well.
You have several options here:
I expect you have a database containing all your access and refresh tokens for your users - so just create a database access from the App2 backend server to the database containing your access and refresh tokens and just check them directly in the App2 via the new database connection.
Create the middleware that will check user authentication from App2 to App1, but as you correctly pointed out, that would cause an extra loading time.
Depending on whether you need the end user to know that he's connecting to "another server" - meaning App2 - you can use Oauth2 authorization - https://www.youtube.com/watch?v=zUG6BHgJR9w
Option 1. seems like the best solution to me
I am curious if anyone has a solution to this unique situation as I have a solution currently, though I feel it is not the most optimal.
The Situation.
I have built an MVC style web application that talks to a web API through http (authenticating via JWT). My web application is secured by appending authorization to its view controllers and redirecting to a Microsoft login endpoint - then directing back to the view where whichever given controller/function handles the request, connects to the API, appends data to the view, etc.
Preferably I would like to use JQuery/Ajax to submit http requests client-side and update a given view with whatever data the user may wish to see relative to the webpage they're on. This way I could control exactly what the user should see landing on the page any which way and submitting requests from web app to API. Also would enable better continuity between requests as there isn't actually a full refresh of the view. All in all it is my line of thought that this execution would lead to a nice user experience.
The Problem.
So the big issue that I have had to circumvent is CORS Policy. I initially attempted to use JS just as I said above but requests would be redirected to the login endpoint and blocked due to there being no CORS header appended to the request.
'So include a policy in your application and append an authorized header to your Ajax outgoing request' you might say, well... you cannot override CORS security around Microsoft's login endpoint.
My Solution.
What I have done simply instead is create HTML Forms around fields the user would pick and chose to specify what data they wanted from the API. Then carry over input data to the returned view via 'ViewData'
and using razor pages of course I can actually initialize JS variables via C# input.
Side Note
I use JS to transform the API data into graphs for the user to see. I am doing this with a JavaScript Library.
My Question to you.
This all leads me to ask then, is there a way to dynamically update a view without using JS? I require a method that can hit the login redirect without being blocked because the request initiated client-side.
Every solution I am aware in some way, shape, or form utilizes JS to make the request. So I am at a loss for how to truly get the functionality I am after without having my requests get blocked due to CORS Policy.
Thanks in advance y'all.
I'm very new in Spring and never really used java for making web. And I'm making a web with a separated frontend and backend services and I'm trying to make an authentication system using Spring Boot Security. How can I do it? Do I put the security on both the service or just one of them? What's the best way to implement it?
The question is subjective and can have too many interpretations based on context. My understanding is that putting security on both front-end and backend is the best way to implement. After a successful backend authentication you should issue a unique cookie to the browser as it allows users to continue using a site without having to log in to every single page. For each subsequent call, the website recognizes the user from cookie data.
You can use this link for a better understanding of dual authentication mechanism.
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.
We are working on an internal MVC3 app that purely uses Windows Authentication. There's a view that does an AJAX call to a controller action that does some processing before calling a web service. The problem we are running into is that if Anonymous access is turned off (as in Windows Authentication is on), calling the service from the controller actions results in a 401: Unauthorized error.
We have run into a problem of the double hop issue where credentials aren't passed correctly from server to server when calling a service within a service. I'm wondering if the AJAX call is somewhat mimicing the same behavior and not transmitting the correct Windows credentials to the controller which then doesn't pass the correct credentials to the web service.
I've seen some posts that shows how to pass a username and password along with the jQuery call but nothing mentions, an effective way, to bring along Windows Authentication with it.
Has anyone run into a similar issue? We would rather not leave Anonymous access on the web service as it is somewhat sensitive data that we would like to control access to.
Do you have identity impersonation turned on as described in this question:
How to get Windows user name when identity impersonate="true" in asp.net?
A colleague did some research over the weekend and determined it may have something to do with Kerberos authentication setup on the server as well as the jQuery call. In order to get around it, we just refactored the web service into a library that the application just references. We made it a web service initially as we thought in the future this data would need to be accessed from other applications. Running into this issue, we will most likely make it into a NuGet package.
Thanks for the comments.