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
Related
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.
I am working on a integration with Salesforce using REST APIs and, as part of the project, I need to send updates to Salesforce and these updates are not user triggered, they are system triggered.
Because of that, what I expect to see on Salesforce Field History is not a user name but the name of our Connected App (the app that made the update).
What I see today is the user name because the way the integration was made initially using OAuth Authorization Code flow.
To change that part of the project, I followed the link (OAuth 2.0 JWT Bearer Flow for Server-to-Server Integration): https://help.salesforce.com/articleView?id=sf.remoteaccess_oauth_flows.htm&type=5
Making that, I was expeting to generate a token for a System, not for a User, but that's not what happened: when I used the token generate from the JWT Bearer Flow and ran the update, the Field History still shows the user name.
What could I do then?
Which are the options in Salesforce to achieve the behavior I'm expecting?
The most important, in my opinion, is to have a Token for our system, not for a user.
Thanks!
Everybody is an user in Salesforce. Even if you access unauthenticated pages (some contact us form? case or lead capture) - it gets tracked under special Guest User.
It sounds stupid but gives you unified interface to control permissions (Profiles/Permission sets). You want guests to access only FAQ articles and make cases? Sure thing, do it in profile, don't get paranoid about people trying to guess right URLs. You think an app was hacked? You can terminate the session just like any other "user". Want to allow login only in certain hours and from certain IP? Sure.
An app connecting with JWT will still need username (main difference being it's "just" certificate for signing the request instead of password).
Your best bet is to create dedicated "Mr System", "SystemX integration" account. It sounds like waste of license but in the long run saves you questions "why did you edit my account at 1 am" and you could even use it as backup account if you use SSO and it ever fails...
I'm looking for some information about a problem that I never thought about, and that I can't find much on the internet (or I'm looking wrong).
Here it is, for a dashboard project in my company, I need to be able to set up a system to store one account per client, or I just have to click on the account in question to connect, like twitter, google or instagram for example.
After the person has added his account, it appears in a list that can switch whenever he wants. Only I don't really see how to set this up, storing the login information in the localStorage? or the jwt token? I confess that I can't find a correct and secure solution as it should be, that's why I'd like to know if some people would have already done that, or if I can be oriented on an interesting solution?
Thanks a lot!
(Sorry for my english, i'm french and it's not perfect ^^)
Do not use localStorage. LocalStorage is not secure at all and can easily be hijacked through any js code running. If you need to store sensitive information, you should always use a server side session.
When a user logs into your website, create a session identifier for them and store it in a cryptographically signed cookie. If you're using a web framework, look up “how to create a user session using cookies” and follow that guide.
Make sure that whatever cookie library your web framework uses is setting the httpOnly cookie flag. This flag makes it impossible for a browser to read any cookies, which is required in order to safely use server-side sessions with cookies. Read Jeff Atwood's article for more information. He's the man.
Make sure that your cookie library also sets the SameSite=strict cookie flag (to prevent CSRF attacks), as well as the secure=true flag (to ensure cookies can only be set over an encrypted connection).
Each time a user makes a request to your site, use their session ID (extracted from the cookie they send to you) to retrieve their account details from either a database or a cache (depending on how large your website is)
Once you have the user's account info pulled up and verified, feel free to pull any associated sensitive data along with it
Issue: I am trying to sign in as a root user for my account from the AWS portal, but now, after I adding my password I keep getting redirected to:
https://portal.aws.amazon.com/billing/signup?redirect_url=https%3A%2F%2Faws.amazon.com%2Fregistration-confirmation#/start, no matter what.
It was working fine till today, first time I've encountered this redirect.
Main Browser : Chrome - Version 62.0.3202.94
Based on what on similar cases found on google I tried the following and still did not manage to sort out the issue:
-Chrome: deleted all the cookies and cache data
-Chrome: restarted the device and also the browser
-Chrome: used incognito mode
-Firefox (an aws member said is the most suitable browser): tried normal and private mode
-Firefox: deleted all the cookies and cache data
-Edge: tried normal and private mode
Someone suggested already to make use of S3Browser, it does not seem as a efficient solution just to access the AWS Portal a few times a week so I am keeping it as the last resort.
If anyone experienced the same issue or has any more suggestions/ideas would greatly appreciate some help.
Thanks in advance.
I faced the same issue. The following fixed it for me:
Change your Amazon email address on www.amazon.com - You can use the same email address by using this trick. Change myemail#gmail.com to myemail+amazon#gmail.com
Use the lost password recovery on the AWS login site to recover the password for the former email address (i.e. myemail#gmail.com).
Use the new password to login on the AWS console with the former email address (myemail#gmail.com)
I just had the exact same problem and it was caused by my Amazon account who happens to have the same email address as my AWS account. Turns out that somehow ends up to be one and the same account. I finally had to change the Email for my Amazon account and reset the password on my AWS account. Now they are nicely separated.
I contacted AWS regarding the issue and they suggested to reset my password by going through https://signin.aws.amazon.com because they saw I have two accounts under the same email address. I did reset my password but this did not help and I was keep getting sent to the same screen to finish my registration.
Due to the fact that I reset my password for my AWS account, when I tried to do some Christmas shopping through the normal https://www.amazon.co.uk it was prompting me with a message saying that I have another account active (the one from AWS I presume). I just reset my password for my https://www.amazon.co.uk account and it seems that the AWS account start working normally again.
Based on this experience if you encounter the same issue, I would recommend to try and reset the password for both AWS and the online shop https://www.amazon.com.
I had this exact same issue that also manifested itself as my amazon account not being associated with our 3rd party seller account on amazon US FBA (in addition to causing the loop on AWS).
I read the answer here and changed my password but that didn't fix it.
Ultimately, I called amazon.com customer support who transferred me to AWS support (the only way to get them is by calling general support and requesting it). They were able to initiate a password reset request which solved both issues (seller account and AWS Login loop).
I solved the problem of being unable to login to the AWS COnsole because of the AWS Sign In Loop by re-syncing my MFA device.
There's a link on the 3rd phase of login, where it asks for your MFA, that says troubleshoot MFA. If you click it, it asks you for 2 consecutive MFA codes and then lets you in.
Had the same issue.. found out was because of AdGuard app. Hope it will help somebody
for test you can try to login aws on iPhone
I would like to use Oauth 2 for an application in Google App Engine with Java, but I dont find any good example of that use, I would be very thankful if somebody could help me please, it is something frustrating dont find good examples, thnak you.
My 2c is avoid oauth2 libraries. Of course opinions may vary, but for me they provide very leaky abstractions, so you end up being dragged into understanding oauth by the back door. For me at least, taking an hour to read the the two pages that tell you all you need to know, and carefully avoiding all the others, will get you where you want to be.
In simple terms, the steps are :-
Call the auth URL with your app/client ID and the scopes you require. Include the "email" scope.
Google will walk the user through login, and (if the first time through) authorisation dialogues
Eventually the browser will redirect back to your oauthcallback url, and pass you an auth code
Call google to convert the auth code to a refresh token. This will also return the user's google ID and an access token.
Store the user ID in your session so you can identify the user subsequently
Persist the refresh token alongside the google user id in a database
On subsequent visits...
If you have the google user id in the your session, you can retrieve the refresh token from your database and use it to generate access tokens as you need them.
If you do NOT have the google user id in your session, go through the steps above. This time, google will NOT prompt the user for authorisation (since it's already authorised), and the refresh token will be blank (since you already have one stored).
Everything you need to know is within the oauth playground page. If you click through the buttons, you will see that it is following the steps I outlined above.
You then need to deal with the possible error situations, eg
user declines permission
user withdraws permission
google expired the refresh token (happens a lot) so you need to re-auth
timeouts
The two pages you need to read are :-
https://developers.google.com/accounts/docs/OAuth2WebServer and the oauth playground at https://developers.google.com/oauthplayground/
Trust me, as long as you know how to form a URL, store a refresh token (it's just a string) and parse a JSON response, then everything you need is on those pages. Except ...
all the documentation skips over the need to preserve the user ID in your session so you know who it is that is accessing your app. If you're on AppEngine, you may be confused by the appengine sample code which uses a separate appengine login. Ignore it. You will be using oauth to authenticate the user so the appengine stuff doesn't apply and is somewhat confusing.
It's actually much simpler than some of the documentation would lead you to believe, and like I said, imho the leaky libraries don't help.
I'm trying to do exactly the same thing and I agree - it is extremely hard to find a good example of this.
I did find this youtube video however and I think it would help: https://www.youtube.com/watch?v=tVIIgcIqoPw.
Its from Google and it is called Getting Started with Google APIs. The last segment of the video deals with authentication.
There are several OAuth 2 client and server libraries for Java listed on this page: http://oauth.net/2/
Here's quick-start documentation for using Apache Otlu: https://cwiki.apache.org/confluence/display/OLTU/OAuth+2.0+Client+Quickstart
If you're accessing a Google API (as a client), you can use the Google client library for Java, which does OAuth as well as API set-up: https://code.google.com/p/google-api-java-client/