We are using Identity Server 4 in an aspnetcore server app with oidc-client.js lib in an angular client. There is a 15 minute token refresh. This is mostly working very well.
Hopwever, for a subset of users when the refresh activity takes place there is a "login_required" response. I am assuming this is because the ID4 server thinks the session cookie has expired? However, the user had just logged in 15 minutes prior and the cookie should have a lifetime of 10 hours (ID4 default setting).
Does anyone have an idea of what may be causing this? Alternatively is there any logging setting I can use to get more debug info?
Thank you!
We tried various browsers and logins but the behaviour is consistent for these users.
refresh token flow so you may be using code flow with angular
so you have one client also for angular for login.
I faced this same issue because the same user logged in with multiple pc so when anyone logged out of his session all same users also logged out in the code flow.
Related
I am creating an electron application that connects to an Database and do POST and GET requests to retrieve and insert data into it, the problem is that in the code i have defined my database uri ( im using mongodb)
const uri = "mongodb+srv://<myusesrname>:<mypassword>#cluster0.wqbiu.mongodb.net/query?retryWrites=true&w=majority"
like in the example above, but if i pack my electron app the connection to the database as well as the credentials its visible if someone unpacks the app.asar file and look in the server.js file how i can solve this problem? i dont want any security breaches neither for me or the people that will be using my application, thanks in advance for any answer :)
An application that requires a secure connection to something cannot afford to have any username's or password's hardcoded into its code.
Instead, a procedure of authentication and authorisation is utilised.
Authentication is used to verify the user. IE: They are who they say they are, often achieved via the use of some type of login form.
Authorisation is used to verify the logged-in user is allowed to access the requested resource. EG: Is this user allowed to retrieve a list of all users email addresses from the database.
As a rough guide, a user will login with their username and password. You could use OpenID as well here if you wanted. Once the user is 'logged-in' you could set a cookie or session and save the session id in the DB against the user. Of course, all of this is done over HTTPS.
There are various ways to control the validity of the session such as but not limited to refreshing the expiration date / time every time the user hits the server, auto timeout if the user has not interacted with the server for more than X minutes, etc.
In your app, the user could try and interact with the database at any time, but if the user is not logged in, the server could return the appropriate response and prompt the user to login. Some form of API here is really the way to go.
If the user is logged in then then next step is to authorise the users request, ensuring they are allowed to perform what they are asking before sending a response back. If they are not authorised to access the resource (EG: Edit another user’s post) then an appropriate response is returned indicating so.
As you can see, securing your app will take some work but the result of not doing so could be devastating to you and your users.
I am using ReactJS as my front end, with a python flask API backend. I have one hole in my application as it stands - when my users close out of the browser, they are not logged out (unless the Cognito refresh token expires).
However, I have read that the refresh token should not expire in a short period of time, and on Cognito, it has a minimum of 60 minutes.
I also have tried and disliked the window onUnload since (A) it only works on the first window/tab you open for the application and (B) reloads also trigger the onUnload.
I am currently considering my option to be on my backend, ie marking the last time I heard from the user and logging them out after 15 minutes if I have not heard an API call for data. However, this seems to bring its own issues (ie not every user will be refreshing the page and looking for data in the 15 minute window, but I could solve that by the onActive (I have an idle timer) whenever the user makes an action, I ping my api to tell it to reset my timer). The other main issue is I don't know how to remotely log someone out of their session in cognito without havign access to their username and passcode which feels like a security issue.
Any and all help would be appreciated
I have a React application which integrates with Quickbooks. The OAuth2.0 flow works most of the time, but for certain accounts the flow will, after logging in with username/password, present a totally blank window. It should present at that point the approval step to grant access to the service (my application).
Does anyone know what the cause may be here? If the error is on Intuit's side, is there any form of remediation?
Again, this is working with other people's production quickbooks accounts... it is only seemingly random ones that will get stuck on the blank page so that they can not authorize the app for Quickbooks.
An example of the URL we send users to is:
https://appcenter.intuit.com/app/connect/oauth2/authorize?client_id=OCLba5bC6aabduQapuVKZKzv0j3bAuYHLbkLM8yB0E7um4ieQV&redirect_uri=https://app.example.com/oauth-redirect&response_type=code&scope=com.intuit.quickbooks.accounting%20openid%20profile%20email%20phone%20address&state=quickbooks-9bptP0PAA1jcZ3LcpzkRZp1tKOyi0pm8HrZeXxqc
I just received the following error when I tried to run a built-in b2c edit policy from portal.azure.com. I have 2 tabs of the portal open. Why am I receiving this error?
Bad Request - Request Too Long
HTTP Error 400. The size of the request headers is too long.
Note: I experienced this same error message when testing active-directory-b2c-dotnet-webapp-and-webapi sample project. The reason provided was I was sending too many cookies. Is it the same problem?
If it is the same problem, shouldn't stale cookies be deleted before creating new ones?
I do see a lot of cookies for https://login.microsoftonline.com
The error HTTP 400: Size of header request is too long generally happens because there's too many cookies or cookies that are too big.
Azure AD B2C's login goes through login.microsoftonline.com, as does almost every Microsoft service (O365, Azure, etc). So if you've got several accounts that you've signed in to across these services, you're accumulating cookies that will cause this problem.
This is bound to happen much more frequently to developers than end users as developers are logging in to the Azure portal with their corporate account, maybe also with a B2C admin account and then testing out their B2C-powered app with multiple logins.
In the long term, the answer will be is to allow Azure AD B2C customers to specify their own custom domain. This gives the application's B2C cookies isolation from everything else in login.microsoftonline.com. As of 2019-06-23, this feature is still under development. You can support this feature and keep track of its progress by voting for it in the Azure AD B2C feedback forum: Customer-owned domains
However, in the interim as workarounds, there are two things you can explore:
Clear your cookies. This will definitely work every time, it's just cumbersome, especially if presented to your end users.
Limit the amount of claims you include in your token. The more attributes you include in your policy, you'll end up with longer http requests which give you less margin for cookies from other Microsoft properties
Note: This is the same question as: http 400: size of header request is too long when signing in user using Multifactor authentication
2018-11 UPDATE:
Azure AD B2C allows you to use b2clogin.com instead of login.microsoftonline.com which will reduce your substantially reduce your exposure to this issue as you'll no longer share cookies with other Microsoft services.
2022-05 UPDATE:
Customer-owned domains is now live, updated the answer accordingly using strikethrough. Also, fixed the feedback link.
If you are encountering "HTTP Error 400 Bad Request - Request Too Long" for your azure account, you may also want to check whether the URL has been updated by microsoft.
In my case, I wanted to check on my Azure subscriptions. I used to go to this URL:
https://account.azure.com/Subscriptions
But very recently it started giving me the "Bad Request Headers Too long" issue.
I checked the URL and found out that it this is now the correct place to access my subscriptions:
https://account.windowsazure.com/Subscriptions
You also may want to check b2clogin.com described here. As per Microsoft:
Cookies are no longer shared with the other Microsoft services.
Just an FYI: I work on B2C team and our people are looking at this issue. This is not the first time, and in fact, we've fixed it in the past so it's possibly a regression. We'll report back as soon as we have more information.
The issue is because of switching between multiple tenants and those creating cookies. We do facing this issue quite often. The only solution as of I know is deleting the cookies.
If you are a chrome lover there is an edit cookie extension, use that and try to delete the cookies of login.microsoftonline.com & portal.azure.com
I think the problem is with the default OWIN implementation used in the sample MVC apps, the only thing you can do is close the browser (and all other instances) and restart.
You can watch the cookie get bigger and bigger and then eventually the browser gives up.
I have not tried the approach above about the plugin but will give it a go as its a bit smoother than killing all your browser windows
I received multiple answers that this was because I was part of too many Active Directories. I was a part of ZERO active directories when I hit this issue. I cleared my cookies and got about two steps before this happened again. The request appears to be sending many, many microsoft cookies, azure cookies, facebook cookie, google cookies, adsense cookies, and linkedin cookies in the request, but deleting them all didn't help. I finally got through using an incognito tab.
tl;dr Try an incognito tab
I am using CakePHP for my application and I was able to integrate the Paypal hosted solution. Users are successfully redirected to Paypal to complete their payment. Once they have completed, they are returned to my website.
At first, it was taking the user to the login page (as the session was getting removed). To prevent this, I have opened the Paypal page in a new window. Now they are not being asked to login again and keeping the $this->Session->read('Auth.User') intact. However, it is not remembering any other session data. For example, I had a session variable 'invoice_number' which is not available after they are returning from the Paypal website.
I have noticed that the session id doesn't stay the same before and after they completed the payment.
I have changed the core.php to reduce the session security by setting it to low, increased the session time, and I have also modified so that it will only start the session if no session id was found (saw this on a CakePHP ticket/bug).
Interestingly, no in Chrome, it remembers all the session variable, the session ids are same and works fine. But in Firfox, it's not working!
Is there anyway to keep the session alive with the same id/ session variables alive so that even after the payment when they are returning, my application knows what the invoice number for this payment was.
Any help would be really appreciated.
Kind regards,
Tasin
try turn off referer checks in core.php, that should do the trick.
Try setting Security.level to something other than high in core.php.
As I wasn't able to find a suitable solution for this problem, I had to find a work around for this.
As I mentioned, when redirecting, the 'Auth.User' information was still intact. I used this to retrieve information which I stored into the database before sending the users to the PayPal website.
Once the payment is completed and the user is returned to the confirmation page on my site, I am retrieving the data from the database based on 'Auth.User' session data.
Not the perfect solution, but for the time being, it is kind of working.
If welcome any solution that is better than this. Please let me know.
Many thanks,
Tasin